USENIX Update

Hello, thanks for reading the USENIX blog devoted to the LISA ’09 Conference! My name is Matt Simmons, and I’m one of the bloggers who will be writing here with daily updates on events at the conference.

Since I live in New Jersey, I took advantage of the extensive rail network in the North East and arrived in Baltimore Penn Station via Am-Trak this morning. I got out of my cab at the hotel and stared up in appreciation. The conference is being held at the beautiful Marriott Waterfront on the inner harbor, and even the overcast sky couldn’t take away from its impressive façade. I checked in with no issues, delivered my luggage to my room, and virtually ran downstairs to check in at the conference desk.

As luck would have it, I ran right into Pamela Howell, who is the video blogger this year. She showed me around the registration area, introduced me to the USENIX staff working the desks, and helped me get registered. By this time, it was right around noon, so rather than barge into the end of a morning session, I waited it out until the after-lunch sessions began.

I spent the afternoon in Maurita Plouff’s “Management Skills, or, Don’t Panic!” training. This class focused on developing successful workers, influence, and communicating with your management, which teaches that people can be loosely fitted into a series of personality types, and each type responds to different stimuli, and can be motivated in varying ways. Successfully managing the people who report to us, our customers, and our managers requires effectively utilizing these techniques.

In addition to telltales and watchwords of each of the personality types, Maurita wove a blanket of stories from her experiences in IT, discussing everything from messenger boys to party lines to ubiquitous computing environments. I enjoyed the depressingly short period of time I was able to attend this training, and if she offers it again next year, I wholeheartedly recommend signing up. It was a great time, and everyone enjoyed participating with tales of their own management experiences.

Tomorrow I’ll be at the “Working with SELinux” training in the morning and “IPv6: An Introduction” in the afternoon. I can’t wait.

Until next time!

-
By Matt Simmons, author of the Standalone Sysadmin blog

It’s Monday afternoon, and LISA is chugging right along! I’m well into my second day of training, and having a great time, and learning a ton that I’m going to take back to work.

After lunch, I’ve signed up for a training course that sounds great: “Beginning IPv6”. It’s something that I’ve been very vocal about in the past. I’m convinced that by the time it’s obvious that everyone should implement IPv6, it will be too late to do it effectively. The most compelling argument to me is that the emerging markets of the world are going to be coming online using IPv6, because in short order, unassigned IPv4 blocks will all be assigned. That isn’t to say that providers aren’t sitting on blocks, but that it’s going to be harder and more expensive, therefore people who can’t buy them will go with the cheaper alternative that IPv6 will offer. They’re going to be your (and my!) future customers. I want to be ready in a couple of years, so I’m going out of my way to learn now. I didn’t learn IPv4 overnight, and I suspect the case will be made for IPv6 as well.

Rudi van Drunen started his presentation not with technical graphs of dwindling IP addresses. He started it with a slide with headers that said “Numbers run out” and “I need this turtle to dance”, and indeed, there was a CGI turtle. It wasn’t dancing. The turtle is from the KAME project. If you visit http://www.kame.net/ with IPv4, the turtle just sits there, but if you connect with IPv6, you get a dancing turtle. As Rudi said, let the dancing turtle be your incentive to implement IPv6.

As I mentioned, IPv4 addresses are running out. NAT has slowed the expansion, but it won’t be enough to quell the tide. IPv4 addresses are running out, and the internet is still expanding and smart phone use is exploding. We need more and more IP addresses. At this rate, our refrigerators are never going to get on the internet. And neither will the children of tomorrow.

In “IPv6…”, we went over the major changes from the IPv4 that we all know and love. The biggest change is undoubtedly the increase in IP address size. IPv4 uses 32 bit addresses. This provides just over four billion addresses. That sounds like a lot, but the 128 bit address space of IPv6 provides for 3.04×10^38 addresses. THAT is a lot of addresses.

Other changes that will influence networking are maximum transmission units (MTUs). The reason is that the typical MTU is 1500 bytes. With the previous IPv4 header taking up a scant 20 bytes, the larger IPv6 addresses double the header to 40 bytes. At least. Unlike the old version, IPv6 headers have multiple optional header additions. Looking at them from the outside in, each header holds a description of the next header inside of it. This provides the ability of nearly limitless plugins. This also leads to large headers, which can begin to take up an increasingly greedy chunk of the 1500 byte MTU. I forsee jumbo frames becoming more and more important as IPv6 becomes more prevalent and additional layers are implemented.

Speaking of additional layers, IPv6 provides the ability to add features into the protocol itself, through the use of these flexible headers. Where as IPv4 required specific packets to build and tear down IPsec tunnels, IPv6 has an optional header for ESP, encapsulating security packets. In other words, encryption. The header itself specifies that the packet contains encrypted information, rather than relying on encryption-protocol specific packets. This is exciting, and definitely makes me wonder about what new implementations will take effect once the protocol becomes more wide spread.

Overall, I’m still convinced that IPv6 is the future, and we’re going to need to learn it. The conversion isn’t going to happen overnight, and it’s going to take time to absorb the new environment. Why not start now with a lab environment and start learning? It’s not time wasted, it’s time invested in your future.

-
By Matt Simmons, author of the Standalone Sysadmin blog

This morning, I’m attending Rik Farrow’s “Working with SELinux” course. As soon as I walked into the room, it became apparent that I’m in the right place. On the screen was the lead slide of Rik’s show, and the title was “Re-enabling SELinux”. For me, that’s so appropriate, because one of the items on my “new machine” checklist is “disable SELinux”. To me, it’s always been a source of irritation that stopped me from performing actions necessary to administer the machine. The most frustrating part was always that I knew it didn’t have to be like that. I knew that SELinux could be a boon to admins who are always concerned with security. I just didn’t know how to make it work.

SELinux is a extension to the Linux code that was developed by the United States Department of Defense and was released to the Linux community in 2000. It was designed to subscribe to the idea of MLS – multi-level secure. This allows for the categorization of various security levels, such as “secret” or “top-secret”. Most system administrators aren’t concerned so much about “secret” and “top secret” so much as “secure” and “vulnerable”, though.

We can use SELinux’s type enforcement to achieve more secure systems. Contexts are assigned to a multitude of operations and objects, and we constrain them using policies that constrain attempted actions.

The tools used to manipulate SELinux aren’t numerous, but the number of contexts is immense. The hardest part sounds like keeping track of what the contexts should be. Fortunately, SELinux includes ways for us to debug our configuration., such as “setroubleshoot”, which takes the log output of SELinux and formats it so that normal humans can understand it. Audit2allow takes audit log messages and converts them into policy statements, so that perceived failures turn into allowed actions. There are also other ways of configuring SELinux so that it’s useful before it’s really in place.

If you have administered a Linux machine, you may have noticed that there are three possible modes for SELinux. The first is “disabled”, and if you’re like many of the people in the class, this is the one your machines are set to.

The second, “permissive” is much better. This allows SELinux to run and watch access attempts, but not to actually constrain them. This de-fanged mode allows us to see what SELinux would have denied, and change our configuration to allow it, or reconfigure the application as necessary.

The third, “enforcing” is the real mode, which not only watches access attempts, like the “permissive” mode, but also prevents access. Once your configuration is correct, switching from “permissive” to “enforcing” doesn’t require a reboot, only a setenforce command.

After completing this training, I’m very much looking forward to working with it on my machines. My new machines are no longer going to default to “Disabled SELinux”. Instead, I’m going to start evaluating how I can leverage the extra security that it gives.

Rik Farrow’s SELinux Training http://www.usenix.org/event/lisa09/training/tutonefile.html#m8

LISA 2009: Rik Farrow on Working with SELinux
By Matthew Sacks

Rik Farrow is a security trainer as well as the Chief Editor for USENIX’s ;login magazine. He is delivering training on SELinux at LISA 2009 and spoke with the USENIX Blog Team about his background and the upcoming SELinux training he will be delivering at LISA 2009; Working with SELinux
http://www.usenix.org/events/lisa09/training/tutonefile.html#m8

Q: Rik, please tell us a bit about your technical background.

Rik Farrow: I began working with UNIX systems in 1982, and became interested in UNIX security in 1984. In 1987, I began teaching UNIX Security classes and was doing so internationally by 1989. I focused on security training from 1994 to 2006, a business that involved way too much travel. In 1999, I created a course for internal use by the NSA.

While my major in college was psychology, I worked for my advisor as a lab tech and a programmer. I really got involved with computers a few years after graduation, as soon as microcomputers made it possible to own my own computer. By 1980, I was a self-employed computer consultant, doing some programming and manual writing at first. By the mid-80s, I was consulting in UNIX sysadmin and security.

I was also the technical editor of UNIXWorld Magazine from 1989-1994, and started editing special editions of USENIX ;login: in 1998. I have written hundreds of magazine articles, most about security, as well as two UNIX-related books.

Q: What inspired you to deliver training on SELinux at LISA?

Rik Farrow: I had a contract where I was building a Linux system for installation in a remote site. The system involved using XEN, and when something didn’t work, the first thing I did was disable SELinux. I did this based on advice I found on the ‘net.

I later found myself wondering why people considered disabling SELinux a useful first step. It didn’t help with my problem at all. So I began to investigate.

I also had some minor involvement in getting SELinux integrated into the Linux kernel. During the first Linux Kernel Developers Summit, I spent a lot of time with Peter Loscocco, one of the key developers of SELinux at the NSA. Loscocco wanted SELinux to become a part of the default Linux kernel, and Torvalds was not interested, but wanted a more flexible set of hooks instead proposed by Crispin Cowan. I encouraged Loscocco to go along with this scheme, which later became Linux Security Modules (LSM).

Q: Why is SELinux a good choice for securing Linux systems?
Rik Farrow: SELinux is one of three popular policy engines that work with LSM. There are others, such as AppArmor (in SuSe and Debian) and LIDS, but SELinux is the most widely used. Because of its ‘popularity’, there is a lot more support for SELinux.

SELinux provides strong isolation for many services and applications. The pre-packaged policy modules do this well out of the box But SELinux alone is not sufficient protection. You still need to practice good security practices, for example, use of strong passwords, proper file/directory ownership/permissions, and patching.

Q: Is SELinux difficult to implement properly?

Rik Farrow: SELinux works well if you stick with the default policy. The default policy is called the targeted policy and focuses on sandboxing services and troublesome applications. You can also download and use the strict policy, but doing so is a lot harder. The targeted policy allows logged in users a lot of flexibility, while the strict policy locks down users as well.

Q: What benefits does a system administrator get by using SELinux?

Rik Farrow: Exploitable bugs in applications are minimized. For example, suppose someone discovers a new bug in BIND’s named that allows shell execution. SELinux prevents named from executing /bin/sh, as well as prohibiting reading and writing any files outside of the few files required by normal named functioning. The same is true for sendmail and many other services.

SELinux also confines the Apache httpd, but the problems with Web servers most often have to do with bugs in applications that interface with Apache. For example, the recent exploits in the WordPress blogging software would have been severely limited in scope by SELinux. But an attacker using an SQL injection attack would still be able to access a backend database, as this permission must be granted by SELinux so the Web server and database can work together. So there are limitations to what SELinux can do, limitations based on allowing an application to work without interference. SELinux can and does prevent applications from doing things they are not normally expected to do, such as execute shells, read or write files outside of the application, etc.

Q: What are some highlights of interest covered in your training?

Rik Farrow: The focus of the course is really making it easier to work with SELinux. Doing so relies largely on fixing problems with file context, something that can be done with chcon and semanage. I also show how audit2allow is used to patch policy in a safe manner. Getting to the point of being able to do these things involves understanding enough about how SELinux works, as well as a little bit of necessary terminology.

I’ve spent a long time working with UNIX security, some 25 years. This helped me understand both how SELinux works, as well as how best to explain how it works.

Fedora SELinux Home: http://fedoraproject.org/wiki/SELinux

Rik Farrow’s Web Site: http://rikfarrow.com/

Register For LISA 2009: http://www.usenix.org/events/lisa09/registration/