Does anyone have a (partial?) policy for Tomcat on SELinux "strict"? It's definitely something I'd like to confine, however Java needs tons of permissions. Multiple ports, execmem, log files, fifos, on-demand extracted webapps and so on. :-(

Has anyone started on writing a policy for this beast? If there is any way to confine it actually, given that it's pretty much a system on it's own.

[Update: I'd like to point out that running tomcat on a SELinux 'targeted' system works fine by running tomcat in an 'unconfined' domain. Since tomcat usually isn't run with root privileges anyway, it's not that risky]

If you are trying to setup SELinux, a must-know command for you is "sestatus".

Example output:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 20
Policy from config file:        refpolicy-strict

If it doesn't say "enabled", there is no way it will work. :-)

If it says "Current mode: permissive", SELinux will not block any access (that's why it's called "permissive"). So if you still get an "access denied" error from your web server, your unix permissions are blocking the access.

When asking for help, please include which policy you are running (most likely you'll be running 'refpolicy-targeted', since that is the most usable out of the box). Writing e.g. "sestatus says enabled/permissive/refpolicy-strict" is really helpful, and not much to type, is it?

In a previous post, I claimed that SELinux uses a kind of object-oriented approach, and that this has several advantages over path name based access.

Since SELinux policy isn't actually a 'program', the term is somewhat surprising. It's just one fragement of "object oriented programming" that is available in SELinux, and actually a rather simple fragment. Also it's not how it's evaluated; but the OOP 'design pattern' of 'classes' is somewhat present in the SELinux reference policy. The syntax is kind of twisted, too.

Let me give you a simple example policy fragment:

type mylog_t;
logging_log_file(mylog_t)

This fragment defines a new type, and 'inherits' from the 'log_file' class. (you can think of "logging_log_file" as com.tresys.oss.refpolicy.system.logging.log_file if you are a Java freak)

The logging_log_file 'class' (which technically is a M4 macro, and maps to the SELinux 'typeattribute' 'logfile' - this would be called an abstract class in other programming languages) in turn will make mylog_t also be a "file_type" type attribute.

So above line means that the new mylog_t type will 'inherit' certain access rules. Namely those defined via the logfile type attribute or file_type.

This means that I can write policy to grant access on "any file" (e.g. for security scanners such as 'samhain' or the SELinux relabeling utilities, backup application, etc.) or just to any log files (e.g. for logrotate). Independend of where they live or who wrote the policy for them.

So if I write policy for a custom application, add mylog_t for files living somewhere in /home/myapp/logs, I don't need to modify the logrotate policy, because that policy contains:

logging_manage_all_logs(logrotate_t)

Macro names in the reference policy usually start with a namespace prefix. In this example, it's logging_. Since it uses M4 for processing the files, the syntax is largely determined by what is easy to use in M4.

I didn't intend to write (ok, rant...) on this topic again, but a few days ago, this "AppArmor FAQ", was posted to the Linux Kernel Mailing list. Again, this is a lot of 'marketing stuff', and doesn't have the facts quite right...

Some quotes:

In the traditional UNIX model, files do have names but not labels, and applications only operate in terms of those names.

No. In the traditional UNIX model, filenames point to inodes, and the inodes contain data such as file modification dates and permissions. This is where SELinux stores the labels it uses for access control. In fact, the "unix owner" and "unix group" are pretty much the same thing as SELinux labels. And also work pretty much the same way.

Contrary to popular belief, AppArmor is *not* "Pathnames R Us", but rather "Use native abstractions to mediate stuff": when you mediate something, you should use the native syntax that users normally use to access the object.

Maybe the appropriate term would have been "naive abstractions"?

And, no, security systems shouldn't be designed around what a user can easily grasp, because that might just not work... it should be designed around the way resources are handled and how you can successfully restrict access.

"Contrary to popular belief", SELinux *does* use path names. Actually in a very convenient way for the users. So I wouldn't claim SELinux is really harder to use than AppArmor because of its use of path names.

The difference is that SELinux doesn't rely on the path names, but it still gives the user the possibility to use them. In fact, the only way I know to get a proplerly labeled filesystem is based on path names.

If I'd for example keep my web stuff in /home/www, I can tell SELinux that the appropriate label is httpd_sys_content_t by doing

semanage fcontext -a -t httpd_sys_content_t /home/www
restorecon -R /home/www

In AppArmor, I'd need to modify the policy for several applications to achieve this, because of it's dependency on path names. SELinux also uses an abstraction. One that is very convenient for users actually. SELinux does access control on object classes. What I'm doing in above example is to put these files into the "Web site data files" class. So please stop scaring people of "labels". That is just the technical term for what is an "object class", a concept every developer will be familiar with. (SELinux policy development has a couple of OOP-like features, btw., for example it is possible to give an application access to 'all log files'.)

There are, however, some true statements hidden in there:

We also acknowledge that pathname based access control requires a way to perform pathname matching in the kernel, and this comes at a cost higher than comparing object labels [...]

So by providing string matching in the kernel, AppArmor trades run-time performance to grant reduced administrative work.

It is however not obvious how large the difference in "reduced administrative work" is between AppArmor testing the filename "run-time" compared to SELinux using filenames to relabel files "on demand" (or, with restorecond, even on creation by using inotify).

What I still seriously dislike is the FUD spread by AppArmor people such as

Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have.

Why should this only be useful to "intelligence agencies"? Some people live in countries with very strict privacy requirements, and we might want to use these techniques to lessen the risk of leaking data. In AppArmor, I can copy a file with private customer data to the web server directory, and it becomes readable by the web server. In SELinux, the file will still be unreadable by the web server. Does that really sound like "only useful to intelligence agencies" to you?

Dear AppArmor people, please stop trying to invoke fear of the NSA, just to make people use AppArmor. That makes you look very untrustworthy, you know...

The SELinux kernel code is part of the Linux kernel, AppArmor is not. So in theory, that code has been reviewed much better than yours, and is maybe even less likely to contain a "NSA backdoor" than yours. Changes to SELinux are openly discussed on a mailing list, and go through peer review there. They foolow a very strict coding style, which makes review easier; obfuscated code doesn't have a place there. It's not like we were running a binary blob from the NSA we can't have a look at.

Some more comments on AppArmor, since some people might see my previous post just as being disappointed by seeing it in Ubuntu, and not much work on SELinux.

First of all, I should note that I don't have any SELinux systems I'm responsible for anymore. They still run SELinux in strict and are doing well, but I'm no longer responsible for them. So I'm actually pretty much out of SELinux development nowadays. I did some occasional policy merge to monitor policy development, and when I tried VMware, I even setup a SELinux system to check the current state. But I wouldn't call myself an active developer or even user. So I don't think I'm as biased as you might think I am.

Some things why I don't trust the AppArmor people:

• their website is incredibly full of marketing blah-blah such as "AppArmor is the most effective and easy-to-use Linux application security system available today" (effective as in what?)
• their Wiki/FAQ states wildly inaccurate things about SELinux such as "To get the full power of SELinux, applications must be recompiled and linked against SELinux libraries." (no, you don't need to recompile and relink all your applications...) - and they even contradict themselves to some extend; on one hand they claim that you don't need to modify applications for use with AppArmor, on the other hand they highlight it as a feature that you can patch your apache for AppArmor to get some more security for embedded interpreters such as PHP. This is pretty much the same as with SELinux.
• they state such misleading things as "every user should give each system an afternoon's test to decide which is a better match for their needs." - sounds good at first sight, but how many admins are able to evaluate the security of a kernel-based security solution such as AppArmor or SELinux in one day? What this actually is, is an encouragement for admins to pick the security solution because of ease-of-use, not because of security considerations.

Instead they should be honest about what AppArmor can, and what it can not do. I don't doubt that it can be used to make exploits with specially crafted PDF files in evince and such simple viewer applications a lot harder, but their security is not as thorough and complete as SELinux. They are potentially vulnerable to some attacks caused by their path name based approach, or that they cannot do MAC for files with unpredictable names such as most of /proc (e.g. /proc/1234/cmdline), any kind of sockets or when file descriptors are passed from one application to another.

They should also admit that since SELinux initially assigns file labels by very similar pathname/filename patterns as AppArmor uses, it maybe isn't that much harder to setup in this aspect... In fact, it's much easier in SELinux to add an additional location for font files, since all the application policies don't need to be modified or reloaded, just the new font directory needs to be relabeled. In AppArmor, you'd need to modify an 'abstraction', then reload any policy that depends on this abstraction (you probably can only reload all at the same time, so that's not too hard).

To anyone with a tiny bit of computer science knowledge, it should also be obvious that the performance of reconstructing the file path and matching it against a large set of filename globs (AppArmor) necessarily is slower than just using the security label in to the files attributes (SELinux, where this globbing was done once when doing the relabeling); any performance difference that shows that SELinux is slower than AppArmor is probably caused by SELinux doing a lot more security checks than AppArmor. So even AppArmor could benefit from using labeled security...

I'm cool with saying that AppArmor is easier to get started with than SELinux, but they need to be honest about the differences to SELinux and the problems with AppArmor.

Ubuntu got AppArmor support.

This is bad news. AppArmor is a weak design. IMHO it gives the users a false impression of security, while leaving too much open to bypass security.

But the biggest problem IMHO is that noone at Ubuntu seems to be working on their SELinux support. All I've seen is Ubuntu users breaking their system to a point where they didn't know how to fix it in the attempt to install their SELinux packages. The packages are mostly a 1:1 copy of the Debian packages I guess, but for example their new 'upstart' init-replacement likely isn't capable of actually starting a SELinux enabled system. Oh, and Debian didn't include the relevant package in any 'stable' release, Ubuntu had it in 'universe' since 'warty'. Right now, feisty will include the package, though it reportedly can't be installed.

In the example used in the blog, evince is maybe protected from exploits by bad PDF files, but if you do a cp /usr/bin/evince /tmp and run that copy, all the protection is gone. A symlink might already be sufficient! So AppArmor is heavily relying on the user playing nicely.

You might want to read this Article at LWN about AppArmor and why it's having a hard time getting into Linux mainline and "Security Anti-Pattern: Path based access control" in Joshua Brindle's "SecurityBlog" for a detailed article on the weaknesses in AppArmors approach.

And their constant claim of being easier to use than SELinux isn't true either:

the 'learning' mode itself will only generate you an incomplete policy. It's about as much as you can achieve in SELinux by transforming audit errors to allow rules using the "audit2allow" tool. Maybe even less; for example when an application accesses a font file, SELinux audit2allow will generate a rule that allows access to all font files (since they have the same type). This doesn't rely on any directory globbing magic, but because there is a type for font files. I expect that future versions of audit2allow will actually recommend which interfaces to add instead of just listing raw allow statements.

AppArmors 'abstractions' seems to match what is called 'interfaces' in SELinux, except that interfaces in the SELinux reference policy are well documented and much more extensive. The 'abstractions' offered look like an early, incomplete version of the old NSA policy to me, before this was restructured to become the 'reference policy'.

Interaction between processes also seems to be completely ignored by AppArmor. So it seems to me that "preventing evince from trashing your home directory when opening a malicious PDF file" is pretty much all you can do with AppArmor?

But again, this isn't so much about bashing AppArmor or Ubuntu. I'm just disappointed that noone at Ubuntu seems to work on the more sound and solid SELinux. Most of SELinux is already in Ubuntu (inherited by their Debian roots), but it's lacking some integration work and such. Ubuntu is often said to be more agile than Debian and better at adopting new technologies, but in my experience, this often is limited to 'visual' stuff. If Debian were better at recruiting new people (for example in the SELinux section, we also seriously lack manpower), I'd probably be annoyed by Ubuntu 'trying to be first with all the pretty stuff' (yes, saying this would not be fair, that's why I'm putting it in quotes). Right now I'm mostly happy that they 'divert' many newbies off Debian and to their huge forums. Although it occasionally means I need to help an Ubuntu user to fix his system when he doesn't get any help there.

Debian is participating in the Google Summer of Code again.

Russell Coker offers to mentor SELinux projects, and so do I. I'm available for mentoring SELinux and Debtags related projects in particular.

This years idea pool in the Debian Wiki. Make sure to also check last years idea pool (some of which will no longer be open, though). And of course your idea doesn't need to be on these pages already; we're of course interested in anything that goes beyond that.

One thing with SELinux I'm particularly interested in is install scripts. That is quite some work to do, and you might want to automate it somewhat.

Debian install scripts can be quite complex. Some things are obvious such as restarting services on upgrade. But some scripts do much more.

SELinux uses a deny by default approach (which is the only sane security approach, btw.); in particular this means that many Debian install scripts will be failing.

Right now, package postinst scripts are being run with the full permissions of the apt-get domain. It would be good to reduce that to a "postinst" domain. It would be a possible GSoC project to analyze which permissions package postinst scripts need, and if we can e.g. add a "postinst extended" domain for just a few postinst scripts that really need extended permissions.

An example for extended postinst tasks in Debian (I don't think Redhat, Fedora or Gentoo does that yet): precompiling all python modules for all installed python versions (and to avoid having programs try to precompile them on demand, which will result in audit errors and such). I wrote a module for that called python-support. It adds a restricted domain which can exactly do this task of precompiling Python. But there is other such stuff, such as updating the menus, managing alternatives etc.

But feel free to suggest your own ideas.

Russel Coker explained how to generate a local policy module from the error log.

Note that this approach (audit2allow) suffers from the same problems that automatic policy learning suffers from (at least when not done very smartly). The generated policy will exactly cover the behaviour you had during logging; functionality that you didn't use is not covered, but misbehaviour that occured during this time is.

Thats basically why SELinux doesn't use this autolearning approach considered a "benefit" of AppArmor by some (as you've just seen, you can do that with SELinux, too).

So let me show you an alternate way: First of all, install the refpolicy-*-dev (from my experimental repository on alioth) or selinux-policy-refpolicy-dev (unstable) packages.

Next you'll need an audit error to fix, e.g.:

audit(1173577161.426:3436296): avc:  denied  { search } for  pid=23862 comm="amavisd-new" name="lib" dev=md2 ino=63745 scontext=system_u:system_r:amavis_t tcontext=system_u:object_r:var_lib_t tclass=dir

So that obviously is amavis trying to access /var/lib (you can verify this by checking that ino= is the inode number of this directory). Looking at /var/lib/amavis reveals that these files are labeled amavis_var_lib_t, so the amavis policy is lacking just this simple tweak.

While Russel's approach would work fine, I'll try to show how this would be fixed in the actual policy. The approach I use is documented somewhat in the README.Debian at least in my packages.

I'll create a file named amavisfix.te:

policy_module(amavisfix,1.0.0);
require {
        type amavis_t;
}
files_list_var_lib( amavis_t )

The name "files_list_var_lib" was looked up in the Refpolicy API documentation. Granted, it takes some time to get used to their naming scheme, but it's actually quite consistent.

Now I run

make -f /usr/share/selinux/refpolicy-strict/include/Makefile

Note that "files_list_var_lib" has an actual semantic meaning what the process is being granted; audit2allow lines are just technical representations of the access violations seen.

Some of the more advanced SELinux IDEs might be able to suggest you appropriate interfaces by looking at the audit errors; I havn't tried them yet.

I have not been active with SELinux recently. I was seriously lacking motivation, and recently the old server I was using to test my SELinux stuff died because of a hardware failure.

But these days I installed vmware, and in order to try it out, I decided to install a SELinux Debian etch system. Then I also updated my policy packages.

I actually did quite some progress on the packages; I not only merged the latest upstream SVN version, I also fixed a couple of Debian policy issues (or worked around them), and added some new functionality.

First of all, I extended the update tool (now called update-selinux-policy). It will not only install the current version of each module, but also rerun autodetection and install additional modules if you added software in the meantime (it won't do the relabeling for you, though). This should make system administration a lot easier.

The packages now come with a -dev companion, which includes the interface files. The README.Debian file details how you can use this to build a custom policy module, and the policygentool included will actually generate a template for you. This should make the development of policy modules a lot easier.

Grab the policy packages from my experimental refpolicy directory.

Note: while they share the "refpolicy" source name with the packages in Debian main, they are packaged independently. Manoj is maintaining the official packages, and I never learned how his Makefiles work, so I'm sticking to my own packaging for my development stuff.

Oh, and for me they don't work in enforcing strict mode at boot yet. Policy is still incomplete for Debian (but down to ~25 audit errors). Targeted mode works in enforcing at boot time. The main issue seems to be the way Debians init ramdisk is working and the /dev directory is populated.

But maybe I can host a SELinux-enabled basic vmware image somewhere you could use for cloning yourself SELinux servers as needed.

I don't think I'll keep the packages updated frequently, sorry, and I don't think I'll have time to get enforcing working for strict, either. :-(

Merry Christmas!

I'm catching up with some RSS feeds, including the Linux Weekly News (LWN). This is a high-quality news site for Linux, and being issued just weekly is a nice feature for all those suffering from information overload.

They had an interesting article some weeks ago on Virtual Machines and Memory Protection. If you are interested in system and application security, this is an interesting read.

SELinux has permissions called "execmem" and "execstack". Basically these allow applications to map some memory executeable, or execute their own stack. Back in the assembler days, some techniques relied on this, but it has lately become frowned upon: most buffer overflow and other attacks used by viruses and worms relied on an executable stack or memory. Recently, Intel and AMD added support for "non-executable" bits for memory maps, i.e. hardware support to enforce these permissions; this was sold as an achievement in application security.

Though this is mostly true - tons of attacks rely on this permission - it's not that easy. Modern programming languages such as Java and C# rely on so called Just-In-Time compilation for fast execution. (And future version of perl and python will probably do that, too.) And JIT requires executable memory, because it basically compiles the VMs bytecode into (optimized) machine code, and executes it.

Now you could say: okay, let's just grant mono and java the execmem permission; (which is also what SELinux does) - and this will probably be okay unless there is some grave error in the mono or java runtime. Or any other native library they use. And this is where the problems start: both Mono and Java rely to a certain extend on native libraries. For example the GTK libraries for the UI. Mono applications can also use gstreamer, gnome-vfs, zlib, libpng, libjpeg, ...

That means, security issues in these libraries that need execmem and would not work on native applications can suddenly be exploitable in mono and java apps.

Since we can't do without execmem for Java and Mono: the executable bit for memory does add some extra layers, but doesn't give you full protection from this kind of attacks, sorry. No magic "my computer is no longer hackable because I have the NX bit".

With an NX Bit capable operating system such as Windows XP SP2, harmful viruses are stopped before it can cause any damage to the system.

Russel Coker has posted a SELinux on Debian etch in 5 Minutes guide.

Some small things to note:

• This is for etch, which has Linux 2.6.18 - there are SELinux changes in 2.6.19 which require policy version 21, whereas 2.6.18 has policy version 20. Changing it in /etc/selinux/semanage.conf may or may not be enough.
• rjc posted this Policy fix you'll likely need for running enforcing
• strict, while being more secure, will likely require you to write some policy modules on your own
• policy is a snapshot from october, you might want to get an updated policy. However I currently don't have time to work on it, and I just heard that etch was frozen. But maybe Manoj has still time to update the policy and get it into etch...

In #selinux, we helped a user today to get some SELinux working on Ubuntu.

I had posted before that I expect Ubuntu to be rather close to Debian in terms of SELinux support. This is not true.

Ubuntu ships rather old versions of the toolchain and SELinux libraries. I doubt that you can use the reference policy with this toolchain; the selinux policy shipped by Ubuntu is no longer supported.

Still these would mean that SELinux on Ubuntu would be in the same shape as it is on Gentoo. If it weren't for this critical issue:

sysvinit (2.86.ds1-6ubuntu8) dapper; urgency=low
 
  * Disable SElinux again, nobody gave me a patch to fix the annoying
    message.
 
 -- Scott James Remnant <scott@ubuntu.com>  Fri,  3 Feb 2006 17:54:55 +0000

Init. The process supposed to load the policy at boot, is not SELinux enabled on Ubuntu. At least the version in hoary. And edgy comes with upstart, which doesn't have SELinux support either, AFAIK.

So to use SELinux on Ubuntu you'll have to build your own sysvinit (sysvinit from edgy might do the job). Or add SELinux support to upstart.

The horror of providing full SELinux support out of the box are install scripts.

Installing files of a package is rather easy. Install them, relabel them. This can be added to the package manager. (And I believe dpkg already does that).

However, package install scripts are becoming more and more complex, and they aren't SELinux aware. And there is a lot of stuff that can go wrong here.

For example, a package might want to generate a configuration file for the service you just installed. If this configuration file is to have the same context as the directory containing the configuration file, there won't be a problem - but if it's to have a different context, the generated file will be incorrectly labeled.

I see two basic solutions to this:

• require by policy all package install scripts to register all files they created (and the registration application could then take care of the appropriate file labeling) - but this will take a long time to be adopted by all packages
• monitor package install scripts for file creation, and relabel them automatically. However, many install scripts will also start the service the package contains; monitoring shouldn't extend to them, so I doubt this will actually work, and still problems might arise to delays in relabeling

Any other smart solution for these problems?

Sometimes I wish we could do without turing-complete postinst scripts...

... actually isn't that bad. Apparently we are the only distribution shipping a modular policy and doing some smart policy module autoconfiguration and having an upgrade helper tool.

Fedora, having undoubtedly the best SELinux support, only started with Core 5 to actually ship a modular built of the reference policy. Target comes with around 5 policy modules, the other stuff is either in the base module, or more likely, running unconfined. Strict however comes with the extensive set of policy modules in the reference policy. Upon installation of the policy package, all available modules will automatically be installed; judging from the package I downloaded changes in the module selection are not preserved.

Gentoo is still shipping the last officially released toolchain, which can't to modular builds and can't compile the current reference policy. So they are also shipping the old policy (as in the selinux-policy-default package, we might actually remove soon).

Ubuntu is probably waiting for us to do most of the work. ;-) I havn't heard of any SELinux progress with Ubuntu for half a year.

So all in all, SELinux support in Debian is rather good. We just need more people to use it and fine tune it. There are a couple of differences among distributions especially in the init scripts, that require policy changes.

To a certain extend, SELinux is like TPM.

On one hand, it can be used to increase security of your system a lot.

On the other hand, it can be used to lock you out some more. Like from your Linux-running Motorola phone. (Note: this phone is not running SELinux, but some other LSM)

The combination of both of course increases security even more.

I was wondering if I should maybe starting using these on the next server I install. Make a mini boot system with an SSHD and use the TPM module to secure this boot system. Then whenever the system is booted, I connect via SSH to type in the passphrase to unlock the encrypted disks.

So when some police decides to seize a TOR server, they'll not be able to read any of the data, even when they seize the complete hardware. (Also do read the followup post, that there are probably no charges being pressed against the tor operators, but the police had to do investigations because of the law.)

The only attack vector (apart from breaking crypto) I see is that they use the TPM to decrypt the boot systems sshd key, and then setup a modified boot system to capture my passphrase. They'll probably need more time to set that up than me to be informed the server was seized (or wonder why it's down). They're not exactly prepared for such defensive measures, I guess. (And again, what's the use for them, when I'm most likely just running a TOR exit node there, not logging any of the data passing through?)

OTOH, I'm not planning to setup any server anytime soon, and for a laptop using an encrypted harddrive should be enough. Maybe add some extra SELinux policy to defend against software bugs and maybe keyloggers. Uwe Hermann just measured the overhead and to me this doesn't look very bad. I mean... it will still be much faster than my current laptop, and this laptop is fast enough for me 99.9% of the time.

[Update: moved to proper tag. selinux, not XML.
You might want to read Harald Weltes blog (of GPL enforcement fame) for more details on it. Apparently it's based off an years of SELinux branch, and the source code is availableat Motorola. Yay for companies adhering to the GPL!]

Just a quick update for SELinux in etch. With Manoj picking up work on it again (you might have noticed the large influx of new SELinux related packages these days, bringing our toolchain up to date again), and rjc having setup a SELinux development box for me, we're actually making some progress on SELinux for etch now. Uwe Hermann also blogged about SELinux on Debian recently.

There are tons of small nuisances with SELinux on Debian left. I've started filing bugs and tagging them with the "selinux" usertag. It's in the details. For example mawk and gawk both try to ioctl any file they read as if it were a serial terminal. Which of course causes SELinux to log an audit error, since the init script or whichever was calling awk didn't have the permissions to ioctl a config file.

Then there is /dev/xconsole - it's created by the syslogd init script (shouldn't maybe this be handled by udev), it's barely used by anyone, and SELinux policy upstream wants to keep it in the xserver policy, and claims its main use is to be able to feed it the output from programs started by the window manager (instead of .xsession-errors). Which is a seriously broken design, since it's not multiuser capable. Anyway, our current options are to

• diverge from upstream in policy, putting xconsole into logging policy
• make xserver an mandatory policy module
• convince the syslogd maintainer to disable xconsole by default
• convince upstream to at least split it out from the xserver module into a separate xconsole module and make that mandatory

Of course I was quickly flamed for filing a bug against exim stating that there currently is no SELinux policy for it, and people thus will have to use postfix or sendmail instead. But heck: people trying out SELinux on Debian will run into this problem, you know. I'd certainly prefer people to use exim instead of sendmail (I'm more of a postfix guy), but unless someone writes a policy for exim, people can't use it with SELinux. I have no idea how exim works (where its queues live, expected behaviour and so on), so I can't write a policy.

Now to start a real flamewar - how about making postfix the new default MTA for Debian with etch? /me runs and hides.

In Bérangers blog, there was this short notice on my cut-down on SELinux work. There are several comments to it, some of which are seriously inaccurate. Quoting bad information in Wikipedia doesn't make it more true either.

>SELinux is OpenSource. The kernel parts *are* in the regular Linux kernel.
Absolutely not. SELinux is a heavily patched Kernel + some tools.
Read http://en.wikipedia.org/wiki/Security-Enhanced_Linux if in doubt.

Sorry, but Wikipedia has a really old quote in there. SELinux is (use the source, luke!) in the mainstream "vanilla" Kernel by Linus Torvalds. There are some improvements which aren't in there yet, but in order to run a SELinux system, you do not need to patch your kernel. Anymore. The code in the Linux kernel works just fine. No serious bugs, just some new features are "incoming", and will go into the next Linux kernel. The last larger change in SELinux was around kernel 2.6.9 or so I think (depends on your definition of "large" of course. But the last time I patched my kernel with a SELinux patch was around version 2.6.7 or 2.6.8.)

All the SELinux code is opensource, has rather strict coding guidelines and there are no magic patches from NSA being applied. (Well, basically use the coding style used in the Linux kernel...) Have a look at the mailing list archives on how patches in SELinux work. The NSA would have a hard time hiding secret spying backdoors in these patches, that will go through some more reviews before ending up in the Linux kernel. So you can trust them exactly as much as the Linux kernel itself. And definitely a lot more than the nvidia or ATI drivers. If I were the NSA and wanted to get a backdoor to many systems, I'd ask ATI and Nvidia to put the backdoors into their drivers. There is plenty of room in there.

AppArmor is not in the stock Linux kernel. And havn't received a warm welcome so far...

Some good new up front:
I'm down to around 10 audit errors on booting my amd64 system in targeted policy. To achieve this I did some small changes to the udev init script, and some larger policy modifications (mostly treating /dev/.static/dev the same way as /dev) (see webSVN changes view).

The bad news:
I'm halting my SELinux development.

I'm moving into a new room today, and the box I've recently been using SELinux on is staying with my dad. After all we bought it for him to surf. So I don't have any computer to run SELinux on (my 4+ years old laptop is way to packed already). And that means I can't seriously work on SELinux much anymore.

Sorry. It sucks to stop tweaking it right before it's done, but I can't do much about it.

[Update: It's not just about the hardware. The hardware is the reason why I can't do much at all, but as you may have seen in one of my previous blog entries, a couple of things in my life are changing right now. I have no idea how much spare time I'll have at my hands. I welcome the offers of sponsorship I've seen, but I can't accept them when I might end up not doing much more anyway. Sorry.]

I'm giving up on backporting SELinux to sarge. Too many changes are needed in too many apps to make them really compatible with SELinux. Nothing serious, but just lots and lots of small things.

For example, the amavisd-new package will need a cronjob modification. This has already been resolved (somewhat) for unstable, but it means I would need to provide a modified amavisd-new package or a backport.

I hope that when etch gets released end of the year (and I actually believe this will happen), many issues will already be resolved. But it depends of course on many people using SELinux in different settings.

My most-annoying-issue with SELinux on Debian: cron bug #333837, open for some 300 days now.

The debian cron package will backup e.g. /etc/shadow, which actually sounds like a quite inappropriate place for this task. And of course it's all in one file named /etc/cron.d/standard, instead of e.g. /etc/cron.d/backup-key-system-files or so, which I could then label backup_exec_t or something else to assign the special privilege of reading shadow files...

It's bugs like these, unhandled for 300 days, together with having the impression of being the only one trying to get SELinux running and receiving basically no support by the SELinux upstream "community" (which is almost exclusively "enterprise", it seems). It's pretty much like everybody wants you to not use SELinux. Or in my case, not enable people to use SELinux on Debian, since I'm not just "joe average user", but actually trying to add SELinux support to the Debian distribution (which would help Ubuntu to get SELinux, too. The Ubuntu people seem to have given up on SELinux already).

Debian has a small app named "savelog" which can rotate logfiles, compressing the old versions and rotating filenames. It's used in a couple of startup scripts and cron jobs.

The script is labeled logrotate_exec_t in SELinux, giving it the appropriate permissions to modify logfiles.

However, it's also used to rotate backup files of e.g. /var/lib/dpkg/status; which is not a log file; the backups are kept in /var/backups, which is somewhat appropriate.

However, the files in the backup dir are labeled backup_store_t, and I'm not sure if I want all logrotate apps to be able to write there...

It would be nice if we wouldn't have

• multiple apps for log rotation (e.g. logrotate, savelog, built-in functionality of some services like metalog)
• Cleaner separation of config files and shell scripts, so SELinux domain transitions could be inserted easier. If you stuff a whole shell script into /etc/cron.d/foobar, you're doing something really bad...

My experimental SELinux for Debian sarge backports have been updated. The core libraries and utilities are updated to the versions just uploaded to unstable.

Therefore, they may of course contain the same bugs as the unstable versions and since I redid the packaging of libselinux and libsemanage - I didn't understand Manojs packaging system, and these packages needed larger modifications for sarge python support - they may also contain extra bugs.

But even users of unstable might be interested in grabbing the "refpolicy" packages from this repository. These packages are now a modular policy. This is possible since the just uploaded toolchain finally has working policy module linking and results in a significantly smaller policy, since you don't have to add rules for software not installed.

To support this, I've written a tool to resolve inter-module dependencies and to automatically install modules matching the software packages you have installed. Expect to see this in the unstable refpolicy packages sometime, too. Maybe someone else will contribute a ncurses frontend to select policy modules.

Please note that bug reports should be directed to the Debian SELinux Mailing Lists. Please use the mailing lists, instead of just contacting me directly.

On a side note, I don't know if I'll be continuing these efforts.

If you have some simple local modifications to your policy (not using many interfaces etc.), you can grab this local module example tarball, and make a proper SELinux module out of your changes. Maybe you can then avoid building your own policy.

Notice that you can't use any macros with this standalone module source, making policy writing there a bit more difficult than necessary. :-(

Based on the Fedora SELinux FAQ.

I still wish we could get rid of the full M4 complexity for building the policy, and instead use something easier to reuse in such situations.

I've updated my gentle introduction to SELinux slides. I'm still improving them in numerous places, as well as writing more. Thanks for all the feedback I've received so far!

(first announcement)

I've been working on some introductory slides on SELinux. They're still far from finished. All I've written so far is some basic terminology, identities, roles, types. I also tried to show how this increases security, though that part is probably still hard to understand unless you know about common attack vectors.

I havn't yet written about the actual policy, policy modules, all the fancy UI stuff available, reachability analysis etc. I probably will not do so:

The goal of the slides is not to give an exact overview over how SELinux works, how to write good policy etc. I also don't claim to have all facts right - instead I want to provide an easy to understand overview over how SELinux works and why it is a good thing. I guess I won't even be flaming AppArmor. ;-)

Thats why I picked the name "gentle introduction to SELinux".

Remember, it's just a work in progress, "the best is yet to come". I really need your feedback (and encouragement -- there is still so much to be written).

Get the slides as PDF here. Feedback is best via email -- erich AT debian DOT org. I intentionally do not have comments in my blog.

Fixes for the SELinux toolchain were posted to the mailing list today by Joshua Brindle, that should enable proper module linking finally.

If they work as expected, we could finally build the polic into modules and just link those modules needed. Right now, a complete policy is several megabytes big. But only few users will have both postfix, exim and sendmail installed etc.

Thank you.

Manoj Srivastava has uploaded reference policy packages to Debian. If you're going to setup a SELinux system with Debian, I'd recommend you to use the new policy packages (which are currently named "selinux-policy-refpolicy-*", but that might be shortened to selinux-policy-* or so sometime, I guess)

This is basically the only SELinux policy tree actively maintained.

The old policy, packages as selinux-policy-default, is discontinued upstream.

SELinux is an official release goal for etch.

However, we're currently far from that. So far, very few developers are actually using SELinux (if any), or even testing it. I won't be doing anything on SELinux for the next 6 weeks at least, more likely 6 months.

So currently I don't see how we can manage this goal, unless more DDs (and of course users; you don't need to be allowed to upload packages) help getting SELinux properly integrated.

(You can run SELinux on etch without having to recompile any software I think, but you'll have to do quite a bit of customizing yourself right now.)

For a coordinated effort to get SELinux into shape for etch, there are Debian SELinux mailing lists, but so far they're basically unused.

[Update: yes, one option is to remove SELinux from the etch release goals. I was in fact rather surprised to see SELinux listed there.]

[Update #2: It was pointed out, that the first occurence of "release goals" in that mail is prefixed by "pet". Don't ask me what the difference between a release goal and a pet release goal is, though. I guess something like being in an official wishlist...]

If you are interested in doing a SELinux related project during the Google Summer of Code, you can submit it to Debian, if it's somehow Debian related.

It would be nice to get some extra tools (e.g. dependency handling, module autodetection) via the Google Summer of Code.

By finally coming forward and "applying" for inclusion into the mainline kernel, AppArmor finally has to face critique on it's approach. And it seems that it's being beaten up quite a bit.

I don't think there is anything in AppArmor that you can't do with SELinux just as good (Yes, SELinux does use labeled files to work around the hardlink issues, but guess how these labels are assigned initially? By pathname. If you have a hard link with two different labels, only one of them will stick.).

You can in fact "learn" your SELinux policies just like AppArmor. That's called audit2allow, and it is frowned upon for good reasons, and only considered to be okay for interim solutions.

There are also tools in development to produce meaningful policies, that is where SELinux really sets itself apart from AppArmor. In AppArmor, you specify for each "confined" application which files it access (and which capabilities), usually by learning these. On SELinux, you basically divide your system into meaningful parts (e.g. logfiles, user mail, user web files) and then specify which kind of access an application is to be granted.

This manual part, deciding which access is allowed, is a big feature. Apparently the AppArmor thunderbird policy has "learned" the setuid permission for thunderbird, which I consider a very bad idea. You can't just learn everything while application may have bugs (or workarounds, or security nets - e.g. it might try to setuid and quit if it succeeds!).

And despite some claims, SELinux does not require you to have a policy for everything on your system. Only in "strict" policy, whereas if you use "targeted" policy, you'll have a so called "unconfined" domain, too.

The AppArmor approach reminds me a lot of what grsecurity 1.x ACLs were doing, back with some 2.4.x kernel. It never worked too well for me, that's why I can't say much about newer grsecurity versions... but to me, grsecurity sounds a lot better than AppArmor. Much more mature.

Up to now, if you had a working modular reference policy, you actually had had luck. There were some bugs in the toolchain that prevented this from working as intended.

• optionals in base were not enabled. So if you built "mta" into base (or, lets say, "init") the parts of the policy to deal with outside modules (e.g. postfix) were just dropped. So you basically had to build a monolithic policy if you want all the connecting rules between base and modules to work. This was fixed recently in refpolicy, but turned up some new bugs:
• One thing turned up was type attributes being broken. When you loaded a certain combination (a couple of modules in base) suddenly tons of key rules would be missing (e.g. for relabeling files, basically any rule that applied to "file_type", i.e. all files) This was fixed by Stephen Smalley in libsepol 1.12.3
• When certain policy files "required" that your policy has certain permissions (e.g. "execute") defined, this could cause checkpolicy to duplicate this permission, so you ended up having two execute permissions, which obviously didn't work right all the time either. Fixed by Stephen Smalley in checkpolicy 1.30.2/1.30.3 (soon on your favourite anon CVS at sourceforge)

Thanks to all who helped tracking this down.

Looks like modular reference policy is now actually working as intended for me. ;-)

In the aftermath of the SELinux Symposium, tons of stuff has been released. (It's only a pity it wasn't released earlier. ;-))

For example MITRE has released polgen 1.3. The web page doesn't tell much yet (as usual documentation is what SELinux is missing most...), but the Slides from the symposium explain what it's about.

I think polgen can probably do at least as much as AppArmors genprof (which I havn't seen a screenshot of in action yet).

There are more SELinux power tools coming up, easier policy languages and so on. Do also visit the Symposium website and check out the other slides and presentations to see what's going on.

The polgen tool might also (like much of the other ways to write a secure policy, instead of learning the policy 100% automatically) be a good way to check applications for intended behaviour. Such things can turn up lots of weird stuff, for example the sshd trying to write to /etc/krb5.conf on a system with kerberos uninstalled, but this config file present.

My selinux-basics package just entered unstable. The package will pull in some of the essential SELinux software to easy installation, contains some tweaks for Debian (e.g. disable legacy ttys via udev, despite them still being enabled in Debian stock kernels) and most importantly contain a tool that tests for some configuration changes required for smooth SELinux operation on Debian (e.g. use pam_selinux in ssh and login, disable /dev/xconsole)

It's still a work in progress; especially this testing/fixing should be made into a modular app, and offer optional auto-fixing of these things when possible. The source currently is in the SELinux backport projects subversion repository.

I'd appreciate your feedback, and of course patches.

Hello, Planet SELinux.

The SELinux part of my blog is now syndicated there, too. I really appreciate SELinuxNews and the new planet. This means that some of my recently raised concerns are already being tackled: fight AppArmor by community support, too, not only technical superiority. ;-)

Some might have read recent news such as Novell SELinux killer rattles Red Hat, or Dan Walsh's critique of Novells AppArmor release, concerned with "unix like fragmentation in the security sector".

While I also do think that SELinux is both more mature in the core system and more powerful than AppArmor (with a big plus being that SELinux is in the vanilla kernel) - I do think that AppArmor can quickly become a true SELinux killer, by just being better documented and easier to use.

SELinux has serious deficiencies in documentation and development community. Almost all the available SELinux documentation is based around the policy as published by the NSA, which is "superseded by the reference policy project". This is the policy currently in Debian and used in the Gentoo SELinux docs - which hasn't received any updates in months now.

The newer "reference policy" is updated every few days, by exporting Tresys' internal SVN into a public CVS on sourceforge.

Dan Walsh claimed "multiple distributions shipping with SELinux including Fedora Core (2,3,4 and soon 5), Red Hat Enterprise Linux 4, Gentoo, Debian, Ubuntu, Suse and Slackware. "

Which is not entirely true. SuSE has AppArmor now, Fedora and RHEL are pretty much the same, and apparently neither Gentoo, Debian, Ubuntu or Slackware are up to date with SELinux. Or actually involved in the current development. So that basically makes 1 distribution using current SELinux and 1 distribution using AppArmor... Looks like a tie to me.

Also with the development it's pretty much down. AppArmor was developed by a small company called Immunix, and is now backed by big Novell, owner of SuSE. Current SELinux is mostly developed by a small company called Tresys, and somewhat backed and used by RedHat. Both have the feeling of "closed door" commercial development, which may be the reason why it reminds some people of the old Unix wars.

Both of course claim to do an open development, with for example the current SELinux Symposium. But if you look closely at the Agenda and the speakers, it's fairly obvious that this is pretty much a business meeting, with some university speakers talking about the security concepts used.

Just one quote from the site:

Developer Summit
An invitation only meeting for the core developers of SELinux to discuss future plans for SELinux and upcoming technologies.

The winner of this "war" between AppArmor and SELinux will be whoever manages to incorporate community development best, and get the other distributions like Debian, Ubuntu and Slackware to support their efforts. Currently neither of them has the air of actively supporting them, which is really bad. Widespread adoption is also where grSecurity has failed before.

I'm trying to put together a SELinux packaging team for Debian and Ubuntu. Current SELinux is still a major pita to get running... so we need to join our efforts in adopting policy to our needs and such.

Upstream development is of an rather "uncooperative" model: both the selinux libraries and the reference policy are updated by a single person each, by exporting an internal VCS to a public CVS on sourceforge. If you want to add patches, you always have to send them through a mailing list, and hope for them to appear in the archive sometime soon. Or not.

While this works okay for the libraries and utilities - which are fairly stable by now - I have doubts that this is appropriate for the policy. Given the amount of fixes/additions we'll need at least for the reference policy, I think more people should have write access to a shared repository. For this I've setup a subversion repository on svn.debian.org, with currently two branches: unmodified upstream and a debian branch. Note that we might also switch to an arch repository, when some big contributors prefer so.

If users of other distributions (Gentoo?) want to join, they are welcome to do so. They can have their own branch, of course, albeit I don't think it's really necessary (maybe I should have named the "debian" branch "alioth-trunk" or so...)

Basically anything is okay with me, that helps the reference policy and SELinux in picking up speed.

If you'd like to get write access, send me an email with your alioth user id. Given the "unmodified upstream" branch, it should be fairly easy to extract patches from our repository to be included upstream, too.

I've been writing SELinux policy these days. Again. This time for the Reference Policy.

I didn't get any feedback back yet for my policy, which is quite disappointing. Still the number of violations on my systems has gone down a lot, so I might actually be able to run strict some time soon. Which would be a major step. Unfortunately, I still have a couple of things to sort out with the utilities. And every now and then there is a new violation - monthly cronjobs for example are not that easy to observe without playing around. ;-)

The Debian/Ubuntu packaging group is growing, and that means it's bigger than the "pretty much nonexistant" it was just a short time ago.

Recent policy files I've written (which of course still contain bugs): dpkg, apt, tor, amavis, clamav.

So I have now installable packages and tools for the mysterious, wondrous SERefPolicy. You can grab them at http://selinux.alioth.debian.org/experimental

Note that I havn't tried using the policy yet. For example, the policy is missing dpkg and apt-get rules. So don't even think of running it on a production system, there is still lots of stuff to do.

But I just, for the first time, managed to use "semodule", and actually add and remove modules from the modular policy. Yay!

Now we just need to rewrite tons of policy in an even cryptier language, using even more M4 macro hell... ;-)

Oh, and then we need to fix that Make bug effecting unstable, so we can actually build the new policy... ;-)

We definitely need more people working on SELinux support in Debian.

zsh: can't write history file /root/.zsh/history

You'll get this error message on logout when your ssh login is to a userid which may not write your home directory (such as staff_t, when logging into root whose files usually are sysadm_home_r).

Here's a simple workaround for you zsh users:

if id | grep -q sysadm_r; then
        export SAVEHIST=1500
        export HISTFILE=~/.zsh/history
        export HISTSIZE=1500
fi

Bash users probably can use

if ! id | grep -q sysadm_r; then
       shopt -u cmdhist
fi

I've recently done a couple of updates to my SELinux backports for Debian stable.

The backports are mostly "No changes" backports; recent improvements include (finally) a SELinux enabled shadow package. Approximately tomorrow I'll also have a new sysvinit package which makes my modifications hopefully obsolete thanks to the maintainers fixing my reported bugs. ;-)

The packages are largely untested, though. I havn't rolled them out on my main SELinux enabled boxes yet. There also is no SeRefPolicy package yet.

I've added two SELinux on Debian mailing lists on Alioth: SELinux-user and SELinux-Announce.

The first one is an open SELinux on Debian user mailing lists, the second will be used for announcements (mostly when something important changes, new stuff is added, something breaks etc.).

Every SELinux on Debian user should probably subscribe to the second. Since there aren't that many user, I guess the -user mailinglist will be rather low-volume for some time, and needs love by those who are already running SELinux on their boxes.

Current SELinux packages contain some breakages... updates are stuck in NEW right now, and I've written some extra notes to the mailing list: notice about SELinux changes.

BTW: On the long run, Debian will likely drop it's current "strict" policy, and migrate to a serefpolicy-based Policy like Fedora already uses. Any volunteers to debconficate the setup process?