LCA 2008 Security Miniconf

Today I gave a talk about Debian security at the security mini-conf of LCA.

Before I started the talk I asked for suggestions as to how to get more entries in my security blogging contest [0]. During the talk I asked for suggestions as to how to get more people involved in security development. One suggestion was to offer incentives. I’m experimenting with that with my blogging contest and may do future variations of the same thing.

I started with describing some of the history of security in Debian (primarily things that involved me in some way):

In 2003 I suggested that exec-shield be a standard feature in Debian kernel images [1]. I created a kernel-patch-exec-shield package in 2003 and Marcus Better took it over in 2004. We are hoping to get it included in Lenny. AMD64 architecture doesn’t need exec-shield as the CPU has separate write and execute bits in the page table, but it would be nice to get exec-shield included before the last P4 machine gets decommissioned.

A presentation at the security miniconf at LCA 2005 on the topic of stack smashing is interesting [2]. At the time Adamantix was a distribution based on Debian which used PaX (similar to exec-shield). Adamantix has gone away. Hardened Gentoo has been available with Pax for all this time (but is not widely used). RHEL and Fedora have been available for all this time with exec-shield…

In mid 2002 I demonstrated the first SE Linux Play machine at a conference in Germany. It was fully operational with root as the guest user. At that time SE Linux support in Debian was essentially complete. Since that time the scope of the SE Linuc project has increased slightly (EG controlling DBUS access) so the amount of work required for full support is greater. Most of that support is in Debian and Etch is basically working with SE Linux (although not quite as well as it was in 2002 due to lack of support for the strict policy). The aim is to have Lenny SE Linux become as functional as SE Linux in Fedora Core 5. While FC5 has more SE Linux features than the SE Linux project supported in 2002 it’s still a great disappointment that it’s taken so long.

FC5 had pam_namespace to polyinstantiate directories such as /tmp. Lenny will hopefully have it.

I described the current status:

The hardening-wrapper package in unstable allows environment variables starting with DEB_BUILD_HARDENING_ to be used to control execution of GCC. Documented on the Debian Hardening Wikipedia page [3]. It’s still a little experimental and may change in the near future, but it works.

Lucas Nussbaum is working on automatically building Debian packages with warnings for security related issues. The aim is to build all packages and maintain a central location for the logs to allow DDs to find and fix the problems in their packages.

The Alioth Hardening project [4] will hopefully get some action soon (the people involved are busy doing work but not updating the project). The current plan is to base the Debian Hardening work around it.

SE Linux in Debian is something that I want to get working correctly. There are still some significant issues that make strict policy unusable (such as correct labelling of /etc/passwd) as of last time I tested it.

Finally I described the future plans. There were many questions about usability features for SE Linux, I mentioned in concept the features that Red Hat and Tresys people are developing (which I often don’t use as I prefer vi for policy editing).

There were some questions about how SE Linux works. More than half the audience indicated that they had used it so I assumed some basic knowledge of SE Linux when describing how SE Linux works in regard to minimum privilege and the benefits of MAC in terms of limiting the scope of attack. I noted that every program has bugs and every program which performs security related tasks (which includes serving data to the net without being owned) should be assumed to inevitably have security related bugs (see the The Inevitability of Failure paper []).

Based on the Twilight of the Books [5] article I decided to give this talk with no slides as an experiment. I talked from notes that I wrote and advised the delegates to read my blog for the details. Not presenting any slides meant that the room lights were all left on, which made things much easier when answering the many questions (I prefer an interactive format to my talks and have more questions than most speakers). It will be interesting to get some feedback from delegates about how they regarded this.

3 comments to LCA 2008 Security Miniconf

  • Is there anything written on secure package installation policy/guidelines (ie. dpkg, install scripts, updating policy) in Debian?

  • In relation to giving a talk without the slides: I certainly agree that I spent a lot longer trying to pay attention to the talk (which was definitely good). Unfortunately, you probably suffered from being a popular talk — with people coming in so frequently mid-talk, and the rate/volume at which you spoke meant that there were frequent gaps between what was delivered by you and what was heard by me.

    A suitable compromise between standard “note” slides and no slides at all may be to have slides that have very few notes at all, but enough to cause people to listen moore attentively to particular key words — for example, when you talked about the Hardening-wrapper, a slide which has “Hardening-wrapper”, and not much more. An advantage of this would be that in cases where the subject of the discussion is mentioned (in this case, hardening-wrapper) you have a bit of insurance against people not hearing you properly.

    In short, I think the “no slides” could have worked with a smaller audience, or with a bit better sound reinforcement, but in this case it didn’t really work, because if was too difficult to hear.


  • […] Helpful Linux Tidbits on Violates Blog Content LicensesChristopher Neugebauer on LCA 2008 Security MiniconfKevin Mark on LCA 2008 Security MiniconfYet another technoblog » Blog Archive » […]