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 Lessons from a Ferry

January 20, 2009 | etbe

On Saturday I traveled from Victoria to Tasmania via the ferry (to attend LCA), they grossly failed in their security measures and provide three lessons for others:

Make it possible for people to read security relevant documents .
Make obeying the rules not be a cost and make the fact known.
Don’t be lazy.

Here is the detail:

When driving towards the ferry in a queue that lasted about 30 minutes just around the last corner there was a sign notifying me of the security rules. As soon as it was visible I started reading it but the security guard started frantically waving at me, the time taken to read it was holding up the queue. Therefore I never discovered the full list of things that I’m not supposed to do.
One rule was that cylinders of gas (such as propane) were apparently banned and should be surrendered – presumably to prevent a gas leak in the confined space of the ship’s hold from risking an explosion. Anyone who did have such a gas cylinder would probably not want to have it stolen by the security people and would be inclined to lie and hope that the security people wouldn’t find it. If they had made it well known that such gas cylinders would be stored in safe keeping for the duration of the voyage and then returned then they would have been more successful.
They wanted to check the luggage compartments of all vehicles. To check the tail-gate of the Kia Carnival van I was driving first required that all the bags which had been put over the back seat be removed (they were resting against the tail-gate and would fall out if it was opened). When the guard realised that they would have to wait for me to empty a lot of luggage out they decided to just trust me that I didn’t have any bad things on board (even though due to point #1 I didn’t know what bad things were). This problem happened a second time when I reached Tasmania and the guards wanted to search for fruit.

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.

Per-process Namespaces – pam-namespace

December 13, 2008 | etbe

Mike writes about his work in using namespaces on Linux [1]. In 2006 I presented a paper titled “Polyinstantiation of directories in an SE Linux system” about this at the SAGE-AU conference [2].

Newer versions of the code in question has been included in Debian/Lenny. So if you want to use namespaces for a login session on a Lenny system you can do the following:
mkdir /tmp-inst
chmod 0 /tmp-inst
echo “/tmp /tmp-inst/ user root” >> /etc/security/namespace.conf
echo “session required pam_namespace.so” >> /etc/pam.d/common-session

Then every user will have their own unique /tmp and be unable to mess with other users.

If you want to use the shared-subtrees facility to have mount commands which don’t affect /tmp be propagated to other sessions then you need to have the following commands run at boot (maybe from /etc/rc.local):
mount â€“make-shared /
mount â€“bind /tmp /tmp
mount â€“make-private /tmp

The functionality in pam_namespace.so to use the SE Linux security context to instantiate the directory seems broken in Lenny. I’ll write a patch for this shortly.

While my paper is not particularly useful as documentation of pam_namespace.so (things changed after I wrote it), it does cover the threats that you face in terms of hostile use of /tmp and how namespaces may be used to solve them.

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…

EC2 Security

October 13, 2008 | etbe

One thing that concerns me about using any online service is the security. When that service is a virtual server running in another country the risks are greater than average.

I’m currently investigating the Amazon EC2 service for some clients, and naturally I’m concerned about the security. Firstly they appear to have implemented a good range of Xen based security mechanisms, their documentation is worth reading by anyone who plans to run a Xen server for multiple users [1]. I think it would be a good thing if other providers would follow their example in documenting the ways that they protect their customers.

Next they seem to have done a good job at securing the access to the service. You use public key encryption for all requests to the service and they generate the keypair. While later in this article I identify some areas that could be improved, I want to make it known that overall I think that EC2 is a good service and it seems generally better than average in every way. But it’s a high profile service which deserves a good deal of scrutiny and I’ve found some things that need to be improved.

The first problem is when it comes to downloading anything of importance (kernel modules for use in a machine image, utility programs for managing AMIs, etc). All downloads are done via http (not https) and the files are not signed in any way. This is an obvious risk that anyone who controls a router could compromise EC2 instances by causing people to download hostile versions of the tools. The solution to this is to use https for the downloads AND to use GPG to sign the files, https is the most user-friendly way of authenticating the files (although it could be argued that anyone who lacks the skill needed to use GPG will never run a secure server anyway) and GPG allows end to end encryption and would allow me to verify files that a client is using if the signature was downloaded at the same time.

More likely problems start when it comes to the machine images that they provide. They have images of Fedora Core 4, Fedora Core 6, and Fedora 8 available. Fedora releases are maintained until one month after the release of two subsequent versions [6], so Fedora 8 will end support one month after the release of Fedora 10 (which will be quite soon) and Fedora Core 6 and Fedora Core 4 have been out of support for a long time. I expect that someone who wanted to 0wn some servers that are well connected could get a list of exploits that work on FC4 or FC6 and try them out on machines running on EC2. While it is theoretically possible for Amazon staff to patch the FC4 images for all security holes that are discovered, it would be a lot of work, and it wouldn’t apply to all the repositories of FC4 software. So making FC4 usable as a secure base for an online service really isn’t a viable option.

Amazon’s page on “Tips for Securing Your EC2 Instance” [3] mostly covers setting up ssh, I wonder whether anyone who needs advice on setting up ssh can ever hope to run a secure server on the net. It does have some useful information on managing the EC2 firewall that will be of general interest.

One of the services that Amazon offers is to have “shared images” where any Amazon customer can share an image with the world. Amazon has a document about AMI security issues [4], but it seems to only be useful against clueless security mistakes by the person who creates an image not malice. If a hostile party creates a machine image you can expect that you won’t discover the problem by looking for open ports and checking for strange processes. The Amazon web page says “you should treat shared AMIs as you would any foreign code that you might consider deploying in your own data center and perform the appropriate due diligence“, the difference of course is that most foreign code that you might consider deploying comes from companies and is shipped in shrink-wrap packaging. I don’t count the high quality free software available in a typical Linux distribution in the same category as this “foreign code”.

While some companies have accidentally shipped viruses on installation media in the past it has been quite rare. But I expect hostile AMIs on EC2 to be considerably more common. Amazon recommends that people know the source of the AMIs that they use. Of course there is a simple way of encouraging this, Amazon could refrain from providing a global directory of AMIs without descriptions (the output of “ec2dim -x all“) and instead force customers to subscribe to channels containing AMIs that have not been approved by Amazon staff (the images that purport to be from Oracle and Red Hat could easily have their sources verified and be listed as trusted images if they are what they appear to be).

There seems to be no way of properly tracking the identity of the person who created a machine image within the Amazon service. The ec2dim command only gives an ID number for the creator (and there seems to be no API tool to get information on a user based on their ID). The web interface gives a name and an Amazon account name.

The next issue is that of the kernel. Amazon notes that they include “vmsplice root exploit patch” in the 2.6.18 kernel image that they supply [2], however there have been a number of other Linux kernel security problems found since then and plenty of security issues for 2.6.18 were patched before the vmsplice bug was discovered – were they patched as well? The file date stamp on the kernel image and modules files of 20th Feb 2008 indicates that there are a few kernel security issues which are not patched in the Amazon kernel.

To fix this the obvious solution is to use a modern distribution image. Of course without knowing what other patches they include (they mention a patch for better network performance) this is going to be difficult. It seems that we need some distribution packages of kernels designed for EC2, they would incorporate the Amazon patches and the Amazon configuration as well as all the latest security updates. I’ve started looking at the Amazon EC2 kernel image to see what I should incorporate from it to make a Debian kernel image. It would be good if we could get such a package included in an update to Debian/Lenny. Also Red Hat is partnering with Amazon to offer RHEL on EC2 [5], I’m sure that they provide good kernels as part of that service – but as the costs for RHEL on EC2 more than double the cost of the cheapest EC2 instance I expect that only the customers that need the the larger instances all the time will use it. The source for the RHEL kernels will of course be good for CentOS (binaries produced from such sources may be in CentOS already, I haven’t checked).

This is not an exhaustive list of security issues related to EC2, I may end up writing a series of posts about this.

Update: Jef Spaleta has written an interesting post that references this one [7]. He is a bit harsher than I am, but his points are all well supported by the evidence.

The Security Benefits of Being Unimportant

October 7, 2008 | etbe

A recent news item is the “hacking” of the Yahoo mailbox used by Sarah Palin (the Republican VP candidate) [1]. It seems most likely that it was a simple social-engineering attack on the password reset process of Yahoo (although we are unlikely to learn the details unless the case comes to trial). The email address in question had been used for some time to avoid government data-retention legislation but had only been “hacked” after she was listed as the VP candidate. The reason of course is that most people don’t care much about who is the governor of one of the least populous US states.

Remote attack on a mailbox (which is what we presume happened) is only one possible problem. Another of course is that of the integrity of the staff at the ISP. While I know nothing about what happens inside Yahoo, I have observed instances of unethical actions by employees at some ISPs where I have previously worked, I have no doubt that such people would have read the email of a VP candidate without any thought if they had sufficient access to do so. If an ISP stores unencrypted passwords then the way things usually work is that the helpdesk people are granted read access to the password data so that they can login to customer accounts to reproduce problems – this is a benefit for the customers in terms of convenience. But that also means that they can read the email of any customer at any time. I believe that my account on Gmail (the only webmail service I use) is relatively safe. I’m sure that there are a huge number of people who are more important than me who use Gmail. But if I was ever considered to have a reasonable chance of becoming Prime Minister then I would avoid using a Gmail account as a precaution.

There is a rumoured Chinese proverb and curse in three parts:
May you live in interesting times
May you come to the attention of those in authority
May you find what you are looking for [2]

In terms of your email, everyone who has root access to the machine which stores it (which includes employees of the companies that provide warranty service to all the hardware in the server room) and every help-desk person who can login to your account to diagnose problems is in a position of authority. Being merely one of thousands of customers (or millions of customers for a larger service) is a measure of safety.

As for the “interesting times” issue, the Republican party is trying to keep the issue focussed on the wars instead of on the economy. The problem with basing a campaign on wars is that many people will come to the conclusion that the election is not about people merely losing some money, but people dying. This could be sufficient to convince people that the right thing to do is not to abide by the usual standards for ethical behavior when dealing with private data, but to instead try and find something that can be used to affect the result of an election.

Mail that is not encrypted (most mail isn’t) and which is not transferred with TLS (so few mail servers support TLS that it hardly seems worth the effort of implementing it) can be intercepted at many locations (the sending system and routers are two options). But the receiving system is the easiest location. A big advantage for a hostile party in getting mail from the receiving system is that it can be polled quickly (an external attacker could use an open wireless access-point and move on long before anyone could catch them) and that if it is polled from inside the company that runs the mail server there is almost never any useful audit trail (if a sysadmin logs in to a server 10 times a day for real work reasons, and 11th login to copy some files will not be noticed).

One of the problems with leaks of secret data is that it is often impossible to know whether they have happened. While there is public evidence of one attack on Sarah Palin’s Yahoo account, there is no evidence that it was the first attack. If someone had obtained the password (through an insider in Yahoo, or through a compromised client machine) then they could have been copying all the mail for months without being noticed.

It seems to me that your choice of ISP needs to be partly determined by how many hostile parties will want to access your mail and what resources they may be prepared to devote to it. For a significant political candidate using a government email address seems like the best option, with the alternative being to use a server owned and run by the political party in question, if you can have the staff fired for leaking your mail then your email will be a lot safer!

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.

DKIM and Mailing Lists

October 3, 2008 | etbe

Currently we have a problem with the Debian list server and Gmail. Gmail signs all mail that it sends with both DKIM and DomainKeys (DomainKeys has been obsoleted by DKIM so most mail servers implement only one of the two standards although apart from space there is no reason not to use both). The Debian list servers change the message body without removing the signatures, and therefore send out mail with invalid signatures.

DKIM has an option to specify the length of the body part that it signs. If that option is used then an intermediate system can append data to the body without breaking the signature. This could be bad if a hostile party could intercept messages and append something damaging, but has the advantage that mailing list footers will not affect the signature. Of course if the list server modifies the Subject to include the list name in brackets at the start of the subject line then it will still break the signature. However Gmail is configured to not use the length field, and a Gmail user has no option to change this (AFAIK – if anyone knows how to make Gmail use the DKIM length field for their own account then please let me know).

I believe that the ideal functionality of a sending mail server would be to have the configuration of it’s DKIM milter allow specifying which addresses should have the length field used. For example I would like to have all mail sent to an address matching @lists\. have the length field used (as well as some other list servers that don’t match that naming scheme), and I would also like to be able to specify which recipient addresses should have no DKIM signatures (for example list servers that modify the subject line). I have filed Debian bug #500967 against the dkim-filter package requesting this feature [1].

For correct operation of a list server, the minimal functionality is implemented in the Mailman package in Lenny. That is to strip off DKIM and DomainKey signatures. The ideal functionality of a list server would be that for lists that are not configured to modify the Subject line it would leave a DKIM header that uses the length field and otherwise remove the DKIM header. I have filed Debian bug #500965 against lists.debian.org requesting that the configuration be changed to strip the headers in question in a similar manner [2] (the Debian list servers appear to use SmartList – I have not checked whether the latest version of SmartList does the right thing in this regard – if not it deserves another bug report).

I have also filed Debian bug report #500966 requesting that the list servers sign all outbound mail with DKIM [3]. I believe that protecting the integrity of the Debian mail infrastructure is important, preventing forged mail is a good thing, and that the small amount of CPU time needed for this is worth the effort.

Also the Debian project is in a position of leadership in the community. We should adopt new technologies that benefit society first to help encourage others to do the same and also to help find and fix bugs.

etbe – Russell Coker

Linux, politics, and other interesting things

Category Archives: Security