Status of SE Linux in Debian LCA 2009

January 20, 2009 | etbe

This morning I gave a talk at the Security mini-conf of LCA about the status of SE Linux in Debian. Here is a summary of the issues I covered:

General Status

In Lenny (the new release of Debian that will come out in a month or two) SE Linux is working well. Considerably better than in Debian/Etch. There is an installation document on my documents blog [1], it’s very easy, only two scripts need to be run with no parameters to do most of the work (5 commands in total). There is more detail on installing SE Linux in Lenny (and other issues) in the Debian Wiki [2].

The default configuration of SE Linux is “targeted”. Previously we had separate policy packages for “targeted” and “strict”, now they are configuration options for selinux-policy-default. It is also possible to have some users in the unconfined_t domain (like the “targeted” policy) and some in confined domains such as user_t. Changing to strict can be done one user at a time, this needs further documentation.

Backports

I maintain an APT repository of i386 and AMD64 packages for better SE Linux support. This includes libraries built to not need an executable stack (see my previous blog post for details [3]). It also includes i386 libraries that don’t need text relocations AKA execmod (see my blog post about why i386 must die for details [4]).

My Lenny repository includes policy packages before they appear in Testing as well as the packages that are modified to fix the execmod and executable stacks issues. I plan to maintain this repository for some time, at least as long as I am actively using Lenny, but the content will change.

I might back-port the newer upstream policy to Lenny at some later date. If I do this it will be near the time that Lenny+1 is released and I will put it in a different location to my current Lenny repository.

I am currently deciding what to do with packages from external repositories such as debian-multimedia (see my previous post for the background) [5]. I may have to create a separate repository for non-standard Debian packages which I then modify to better support SE Linux.

I also plan to build packages of Security Enhanced PostgreSQL [7] for Lenny and Lenny+1. After demonstrating it’s capabilities I will suggest that it be considered for Lenny+1.

Play Machine

I have been running a Play Machine (open root machine) [6] for most of the last seven years. In the near future (probably the week after LCA) I will upgrade it to Lenny. One thing that I didn’t mention is the fact that I plan to demonstrate other things such as SE-PostgreSQL in Play Machines.

Training

I have a Xen server that is used for my Play Machine, I will run it as a SE Linux training machine and grant temporary ownership of a DomU to anyone who wants to learn and have a document with a list of tasks to complete to learn about SE Linux. I might be able to get it online this week. If so then I’ll make it available first to LCA delegates.

I will also set up a Bittorrent server for a Xen image for anyone who wants to go through the same SE Linux training program on their own machine – this will allow them a greater time limit and also avoid contention for my server. Unfortunately I have some problems with BitTorrent, I would appreciate any advice about running a torrent tracker.

Post Lenny

SE PostgreSQL is an exciting new development that I want to get in Debian. Initially I will create my own APT repository for it and include it in my Lenny repository. Hopefully it will become a standard feature in Lenny+1.

Security Enhanced X (the X window access controls) is a significant security feature. I hope to have that in Lenny+1, but it might not be possible.

Security Enhanced PostgreSQL

January 19, 2009 | etbe

Today was the first day of Linux Conf Au 2009 [1]. KaiGai Kohei was unable to attend the conference and give a database mini-conf presentation about his work on Security Enhanced PostgreSQL [2], so I gave the presentation in his place. It was a fairly difficult presentation and required that I learn a lot about PostgreSQL in a small amount of time. But the result seemed OK, the audience seemed reasonably interested and the questions indicated that there was no extreme negative reaction to it.

After the main presentation I gave a live demo using a Fedora 10 machine image that KaiGai provided. That ended about four minutes after the specified time, which was pretty good considering that I started about seven minutes late to allow the audience time to return from the lunch break.

Tomorrow I will give another talk for KaiGai on the topic of the Security Enhanced LAPP (Linux, Apache, PostgreSQL, and PHP) stack. I will also give a talk about the status of SE Linux in Debian/Lenny.

For both talks I have a separate laptop for the demos, so after tomorrow I will only take one laptop to LCA – which will probably be an EeePC (on some days at least).

Debian Multimedia and SE Linux

January 12, 2009 | etbe

I have just had a need to install packages from Debian-Multimedia.org to correctly play .3gp files from my mobile phone (the stock Mplayer in Debian would not play the sound).

As part of getting this to work in a way that I like I rebuilt some packages so that shared objects would not demand an executable stack and added them to My SE Linux Etch repository [1]. The liblzo2-2 package is in Debian so I filed bug report #511479 against it. Not that I expect it to be fixed for Etch now that Lenny is about to be released. But it’s good to have the data in the bug tracking system for the benefit of all interested people.

The lame and xvidcore packages are only in the Debian Multimedia archive. I’ve sent email to the maintainer with patches. Not sure if he will accept them (again it’s not a good time for filing bug reports about Etch), but there’s no harm in sending them in.

The lame package also required execmod access, but I don’t have enough time to devote to this to fix it. For background information about execmod see my previous post [2].

See my previous post about executable stacks for more background information [3].

The next thing to do is to test this out in Lenny, hopefully I’ll get time to work on this tomorrow.

SE Linux and Decrypted Data

November 25, 2008 | etbe

There is currently a discussion on the Debian-security mailing list about how to protect data which came from an encrypted file. I was going to skip that one until someone summoned me by mentioning SE Linux.

The issue which was raised is that data from an encrypted file can be read from /dev/mem (for all memory of the machine) or /proc/<pid>/mem (for the memory of the process). It was suggested that SE Linux can prevent such attacks, however it’s not that simple.

In most SE Linux configurations there will be a domain with ultimate privileges, examples are unconfined_t for a default configuration (also known as targeted) and sysadm_t for a “strict” configuration. SE Linux differs from many security models (such as the Unix permissions model that we are familiar with) in that there is no inherent requirement for a domain with ultimate privileges. I have in the past written policy for machines in which no domain could read /dev/mem or modify the running policy. This meant that booting from installation media might be required to modify the configuration of the system – some people desire systems like this and have good reasons for doing so!

As the vast majority of SE Linux users will have a “targeted” configuration, and the majority of the rest will have a “strict” configuration with minimal changes (IE sysadm_t will work as expected) there will always be a domain that can access /dev/mem (I’m not certain that sysadm_t can directly access /dev/mem on all variants of the policy – but given that it can put SE Linux in permissive mode it has ultimate access to work around that).

This however doesn’t mean that SE Linux provides no benefit. A typical Linux system will have many daemons running as root, while a typical SE Linux system will have few processes running as root while also having a SE Linux context that grants ultimate privileges. The root owned processes that SE Linux constrains are generally the network facing daemons and other processes which provide a risk, while the root owned processes that are not constrained by SE Linux policy are generally processes related to early stages of the system boot and programs run as part of the system administrator’s login session – processes that are inherently trusted.

Now regarding the memory of the process (and the ptrace API), in most cases a process that is likely to be accessing such a file will run in a domain that permits such access to itself. If the process in question is run from a login session (ssh login etc) then other processes in the same session will have access to the data. It is quite possible to write policy to create a new domain for the program which accesses the decrypted data and to deny the domain the ability to ptrace itself, but it will require at least 10 minutes of work (it’s not a default configuration).

So while SE Linux will generally help you to improve your security no matter what your exact requirements may be, it’s not something that can be used to make such corner cases entirely disappear. In a more general sense the idea that only a single program can access certain data is almost unattainable in a typical system. Among other things to consider is the fact that the Linux kernel is one of the larger programs on a typical Linux system…

RPC and SE Linux

October 7, 2008 | etbe

One ongoing problem with TCP networking is the combination of RPC services and port based services on the same host. If you have an RPC service that uses a port less than 1024 then typically it will start at 1023 and try lower ports until it finds one that works. A problem that I have had in the past is that an RPC service used port 631 and I then couldn’t start CUPS (which uses that port). A similar problem can arise in a more insidious manner if you have strange networking devices such as a BMC [1] which uses the same IP address as the host and just snarfs connections for itself (as documented by pantz.org [2]), this means that according to the OS the port in question is not in use, but connections to that port will go to the hardware BMC and the OS won’t see them.

Another solution is to give a SE Linux security context to the port which prevents the RPC service from binding to it. RPC applications seem to be happy to make as many bind attempts as necessary to get an available port (thousands of attempts if necessary) so reserving a few ports is not going to cause any problems. As far as I recall my problems with CUPS and RPC services was a motivating factor in some of my early work on writing SE Linux policy to restrict port access.

Of course the best thing to do is to assign IP addresses for IPMI that are different from the OS IP addresses. This is easy to do and merely requires an extra IP address for each port. As a typical server will have two Ethernet ports on the baseboard (one for the front-end network and one for the private network) that means an extra two IP addresses (you want to use both interfaces for redundancy in case the problem which cripples a server is related to one of the Ethernet ports). But for people who don’t have spare IP addresses, SE Linux port labeling could really help.

An Update on DKIM Signing and SE Linux Policy

September 21, 2008 | etbe

In my previous post about DKIM [1] I forgot to mention one critical item, how to get Postfix to actually talk to the DKIM milter. This wasn’t a bad thing because it turned out that I hadn’t got it right.

I had configured the DKIM milter on the same line as the milters for ClamAV and SpamAssassin – in the smtpd_milters section. This was fine for relaying outbound mail via my server but didn’t work for locally generated mail. For locally generated mail Postfix has a directive named non_smtpd_milters which you need to use. So it seems that a fully functional Postfix DKIM milter configuration requires adding the following two lines to /etc/postfix/main.cf:

smtpd_milters = unix:/var/run/dkim-filter/dkim-filter.sock
non_smtpd_milters = unix:/var/run/dkim-filter/dkim-filter.sock

This also required an update to the SE Linux policy. When I was working on setting up DKIM I also wrote SE Linux policy to allow it and also wrote policy for the ClamAV milter. That policy is now in Debian/Unstable and has been approved for Lenny. So I now need to build a new policy package that allows the non_smtpd_milter access to the DKIM milter and apply for it to be included in Lenny.

SE Linux in Lenny is going to be really good. I think that I’ve already made the SE Linux support in the pre-release (*) of Lenny significantly better than Etch plus all my extra updates is. More testers would be appreciated, and more people joining the coding would be appreciated even more.

(*) I use the term pre-release to refer to the fact that the Lenny repository is available for anyone to download packages.

[1] http://etbe.coker.com.au/2008/09/18/installing-dkim-postfix-debian/

Play Machine Update

September 19, 2008 | etbe

My Play Machine [1] was offline for most of the past 48 hours (it’s up again now). I have upgraded the hardware for the Dom0 used to run it so that it now has the ability to run more DomU’s. I can now run at least 5 DomUs while previously I could only run 3. I have several plans that involve running multiple Play Machines with different configurations and for running SE Linux training.

The upgrade didn’t need to take two days, but I had some other things that diverted me during the middle of the job (running the Play Machine isn’t my highest priority). I’ve been doing some significant updates to the SE Linux policy for Lenny including some important changes to the policy related to mail servers. Among other things I created a new domain for DKIM (which I previously wrote about) [2]. The chain of dependencies was that a client wanted me to do some urgent DKIM work and I needed my own mail server to be a test-bed. I installed DKIM and then of course I had to write the SE Linux policy. Now that my client’s network is running the way it should be I’ve got a little more time for other SE Linux work.

Execmod and SE Linux – i386 Must Die

September 11, 2008 | etbe

I have previously written about the execmod permission check in SE Linux [1] and in a post about SE Linux on the desktop I linked to some bug reports about it [2] (which probably won’t be fixed in Debian).

One thing I didn’t mention is the proof of the implication of this. When running a program in the unconfined_t domain on a SE Linux system (the domain for login sessions on a default configuration), if you set the boolean allow_execmod then the following four tests from paxtest will be listed as vulnerable:

Executable bss (mprotect)
Executable data (mprotect)
Executable shared library bss (mprotect)
Executable shared library data (mprotect)

This means that if you have a single shared object which uses text relocations and therefore needs the execmod permission then the range of possible vectors for attack against bugs in the application has just increased by four. This doesn’t necessarily require that the library in question is actually being used either! If a program is linked against many shared objects that it might use, then even if it is not going to ever use the library in question it will still need execmod access to start and thus give extra possibilities to the attacker.

For reference when comparing a Debian system that doesn’t run SE Linux (or has SE Linux in permissive mode) to a SE Linux system with execmod enabled the following tests fail (are reported as vulnerable):

Executable anonymous mapping (mprotect)
Executable heap (mprotect)
Executable stack (mprotect)
Writable text segments

If you set the booleans allow_execstack and allow_execheap then you lose those protections. But if you use the default settings of all three booleans then a program running in the unconfined_t domain will be protected against 8 different memory based attacks.

Based on discussions with other programmers I get the impression that fixing all the execmod issues on i386 is not going to be possible. The desire for a 15% performance boost (the expected result of using an extra register) is greater than the desire for secure systems among the people who matter most (the developers).

Of course we could solve some of these issues by using statically linked programs and have statically linked versions of the libraries in question which can use the extra register without any issues. This does of course mean that updates to the libraries (including security updates) will require rebuilding the statically linked applications in question – if a rebuild was missed then this could be reduce the security of the system.

To totally resolve that issue we need to have i386 machines (the cause of the problem due to their lack of registers) go away. Fortunately in the mainstream server, desktop, and laptop markets that is already pretty much done. I’m still running a bunch of P3 servers (and I know many other people who have similar servers), but they are not used for tasks that involve running programs that are partially written in assembly code (mplayer etc).

One problem is that there are still new machines being released with the i386 ISA as the only instruction set. For example the AMD Geode CPU [2] is used by the One Laptop Per Child (OLPC) project [3] and the new Intel Atom line of CPUs [4] apparently only supports the AMD64 ISA on the “desktop” models and the versions used in ultra-mobile PCs are i386 only.

I think that these issues are particularly difficult in regard to the OLPC. It’s usually not difficult to run “yum upgrade” or “apt-get dist-upgrade” on an EeePC or similar ultra-mobile PC. But getting an OLPC machine upgraded in some of the remote places where they may be deployed might be more difficult. Past experience has shown that viruses and trojans can get to machines that are supposed to be on isolated networks, so it seems that malware can get access to machines that can not communicate with servers that contain security patches… One mitigating factor however is that the OLPC OS is based on Fedora, and Fedora seems to be taking the strongest efforts to improve security of any mainstream distribution, a choice between 15% performance and security seems to be a no-brainer for the Fedora developers.

SE Linux in Lenny status – Achieved Level 1

September 10, 2008 | etbe

I previously described the goals for SE Linux development in Lenny and assigned numbers to the levels of support [1]. I have just uploaded a new policy to unstable which I hope to get in Lenny that will solve all the major issues for level 1 of support (default configuration with the unconfined_t domain for all user sessions – much like the old “targeted” policy). The policy in question is in my Lenny SE Linux repository [2] (for those who don’t want to wait for it to get into Unstable or Lenny).

Is SE Linux Unixish?

August 25, 2008 | etbe

In a comment on my AppArmor is dead post [1] someone complained that SE Linux is not “Unixish“.

The security model in Unix is almost exclusively Discretionary Access Control (DAC) [2]. This means that any process that owns a resource can grant access to the resource to other processes without restriction. For example a user can run “chmod 777 ~” and grant every other user on the system the ability to access their files (and take over their account by modifying ~/.login and similar files). I say that it’s almost exclusively DAC because there are some things that a user can not give away, for example they can not permit a program running under a different non-root UID to ptrace their processes. But for file and directory access it’s entirely discretionary.

SE Linux is based around the concept of Mandatory Access Control (MAC) [3]. This means that the system security policy (as defined by the people who developed the distribution and the local sysadmin) can not be overridden by the user. When a daemon is prevented from accessing files in a user’s home directory by the SE Linux policy and the user is not running in the unconfined_t domain there is no possibility of them granting access.

SE Linux has separate measures for protecting integrity and confidentiality. An option is to use MultiLevel Security (MLS) [4], but a more user-friendly option is MCS (Multi-Category Security).

The design of SE Linux is based on the concept of having as much of the security policy as possible being loaded at boot time. The design of the Unix permissions model was based on the concept of using the minimal amount of memory at a time when 1M of RAM was a big machine. An access control policy is comprised of two parts, file labels (which is UID, GID, permissions, and maybe ACLs for Unix access controls and a “security context” for SE Linux) and a policy which determines how those file labels are used. The policy in the Unix system is compiled into the kernel and is essentially impossible to change. The SE Linux policy is loaded at boot time, and the most extreme changes to the policy will at most require a reboot.

The policy language used for SE Linux is based on the concept of deny by default (everything that is not specifically permitted is denied) and access controls apply to all operations. The Unix access control is mostly permissive and many operations (such as seeing more privileged processes in the output of “ps”) can not be denied on a standard Unix system.

So it seems that in many ways SE Linux is not “Unixish”, and it seems to me that any system which makes a Unix system reasonably secure could also be considered to be “not Unixish”. Unix just wasn’t designed for security, not that it is bad by the standards of modern server and desktop OSs.

Of course many of the compromises in the design of Unix (such as having all login sessions recorded in a single /var/run/utmp file and having all user accounts stored in a single /etc/passwd file) impact SE Linux systems. But some of them can be worked around, and others will be fixed eventually.

etbe – Russell Coker

Linux, politics, and other interesting things

Tag Archives: Selinux