FS#21406 - [kernel26] Make sure to configure 2.6.36 with AppArmor

Attached to Project: Arch Linux
Opened by Tomas Mudrunka (harvie) - Thursday, 21 October 2010, 23:57 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 25 October 2010, 20:38 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

Description: Kernel 2.6.36 was released and it supports apparmor. Please make sure to enable it in ArchLinux's kernel26 package :-)
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Monday, 25 October 2010, 20:38 GMT
Reason for closing:  Implemented
Comment by Thomas Bächler (brain0) - Friday, 22 October 2010, 10:02 GMT
We first need to make sure that enabling AppArmor doesn't have any negative effect on people who do not want to use it. Can you elaborate on that?

How I understand it, setting CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=0 should disable it by default, allowing anyone to enable it at boot time.
Comment by Trung Pham (trungpham) - Friday, 22 October 2010, 13:34 GMT
I have been a big fan of AppArmor for a long time. I think Arch security will get better with AA. Please enable it in ArchLinux's kernel26.
Comment by Thomas Bächler (brain0) - Friday, 22 October 2010, 13:44 GMT
If you are a fan, then you might be able to post a proper reply to my previous post. It would be much more helpful.
Comment by Tomas Mudrunka (harvie) - Saturday, 23 October 2010, 03:15 GMT Comment by Pierre Schmitz (Pierre) - Saturday, 23 October 2010, 10:16 GMT
We would also need the user space tools and especially the configuration. Just enabling apparmor in the kernel is not enough. This is quite a big task.
Comment by Tomas Mudrunka (harvie) - Saturday, 23 October 2010, 12:06 GMT
Pierre: it should not be such hard to add userspace tools. but i think that all package maintainers should add /etc/apparmor.d/ profiles for their packages, so everything will run out of box. eg.: you will install webserver or browser and it will be locked in apparmor by default when you enable that option in kernel option line...
Comment by Pierre Schmitz (Pierre) - Saturday, 23 October 2010, 12:40 GMT
It's not hard but a lot of work and doing it right will affect all packagers. My point was that this is not a simple switch in your kernel config. I'd prefer to start with an external project to proof if this really works with arch and is worth the effort. Enabling apparmor in you kernel is most likely the simplest task.
Comment by Tomas Mudrunka (harvie) - Saturday, 23 October 2010, 13:43 GMT
Pierre: well we can just build the kernel and test it. doesn't seem much hard to me...
note that we do not need to affect all the packagers. we can just recommend it to them and then people will fill the requests invidualy if they will want apparmor rules for some specific package... but good start will be making rules for all suid binaries in "base" package group (lot's of those rules are pre made in userspace package for apparmor).

seems that we need some program called apparmor_parser to load profiles to kernel during boot (and during runtime):
http://manpages.ubuntu.com/manpages/hardy/man5/apparmor.d.5.html
http://manpages.ubuntu.com/manpages/hardy/man8/apparmor_parser.8.html

We can also slowly start make some documentation at http://wiki.archlinux.org/index.php/Apparmor (there's already something but it does not seem much usefull to me...)
Comment by Ionut Biru (wonder) - Saturday, 23 October 2010, 14:17 GMT
i don't want any apparmor rules for any packages.

if we look at how we managed selinux, i think we should do the same thing here. let the users do their work if they want that.
Comment by Tomas Mudrunka (harvie) - Saturday, 23 October 2010, 15:46 GMT
wonder: Well it's just single short plaintext file and there's no problem with adding them to packages.
it's architecture bit different from SELinux...
it's MUCH more easy to configure (as you don't need to create and manage contexts, etc...) and i think we can add this few-lines long profile at least for apps that will seem critical to us - it will cost us nearly nothing. and users will get system that can simply get some little more security out of box by adding one simple parameter to GRUB.

so why you do not want that rules? user will be still able to override them...
it's much like applications that are coming with own logrotate.d or sleep.d scripts... it's just the same thing.
Comment by Jelle van der Waa (jelly) - Saturday, 23 October 2010, 16:06 GMT
i would vote for including AppArmor into the stock kernel, then users can use AppArmor or not.
Comment by Pierre Schmitz (Pierre) - Saturday, 23 October 2010, 16:07 GMT
I think at this point it's not wise to decide if this should be ever included in Arch or not. There is too few information and experience available. The best way to get this done is to start implement it for yourself and look for people to join you. Provide a patched kernel pkgbuild, apparmor user space tools (atm there is not a single package in aur) and start writing some profiles for e.g. packages in core. Test these, also let others use them and finally report your experience back here.
Comment by Tomas Mudrunka (harvie) - Saturday, 23 October 2010, 17:23 GMT
jelly: naturally... we can build kernel with AA, but it will be disabled by default and supply profiles for critical packages.
if you will not add it to bootloader (to enable the kernel module) and DAEMONS in rc.conf (to load AA profiles) you will be absolutely unafected.

Pierre: Well as 2.6.36 will arive to core i will make those packages in AUR, so we'll be able to collaborate, debug and make documentation in wiki.
Comment by Jelle van der Waa (jelly) - Saturday, 23 October 2010, 18:31 GMT
Pierre, you're absolutely right.

I will look into setting up a VM with archlinux and an AppArmor environment.
Comment by Thomas Bächler (brain0) - Saturday, 23 October 2010, 22:36 GMT
harvie, thanks, it seems the Documentation from the kernel tree is much more helpful than their wiki. Enabling AppArmor in the kernel should be possible (in contrast to SELinux, which broke everything when being enabled).

I don't think we should include AppArmor profiles into any packages right now, until a sufficient amount of testing and contribution has been done in the community, and we can see how many changes should be done in the packages.
Comment by Vlad George (DonVla) - Sunday, 24 October 2010, 13:50 GMT
But are default packaged profiles really needed?
These can be found online for several applications: http://bodhizazen.net/aa-profiles/

BTW: Here is a pretty comprehensible howto: http://ubuntuforums.org/showthread.php?t=1008906
PS: Afais, under Ubuntu there's an apparmor-profiles package. This maybe also an idea for Arch.
Comment by Tomas Mudrunka (harvie) - Sunday, 24 October 2010, 16:56 GMT
I've tried to build the userspace tools at least, but it wants RPM and the build fails for few more reasons. this probably can be fixed, but i do not have much time in these days, so if someone wants to continue with some effort in meantime i am attaching PKGBUILD skeleton (at least). This is probably the first step to do... then we will be able to test AA on ArchLinux as soon as we will build new kernel (wich is probably as easy as editing few lines in kernel config).

We'll need especially following things in userspace:
libraries/libapparmor (maybe libapparmor should be in separate package too)
parser
utils
profiles (basic /etc/apparmor.d directory and include profiles with macros)

and optionaly also: changehat (pam, apache, tomcat modules for granting permissions during runtime - should go to separate packages!!)

we should do this as split-package.
   PKGBUILD (0.7 KiB)
Comment by Tomas Mudrunka (harvie) - Sunday, 24 October 2010, 17:04 GMT
DonVla: yes. we can package the profiles for common binaries to some standalone package. but i think that profiles for big packages (that are not in base group) like Apache, Postfix or Firefox should not have profiles in that package. They can have it's own profiles packaged in self or there should be some packages like apparmor-apache2, apparmor-firefox, etc... In other words... package apparmor-profiles should contain only profiles from packages in [core]. packages from [extra] and [community] should decide if they want to add profiles in them or if they will add it as external optional dependecy.

BTW there are some macros (profiles that are included and used in other profiles) and those should be included in main apparmor package.
Comment by Phillip Wood (phil) - Sunday, 24 October 2010, 17:49 GMT
[EDIT] Patches are not needed to load, reload or remove profiles, they are only needed for network confinement and some of the other tools [/EDIT]

I compiled a vanilla 2.6.26 kernel with AppArmor and the userspace utils (http://launchpad.net/apparmor/2.5/2.5.1/+download/apparmor-2.5.1.tar.gz ) this weekend. Unfortunately it appears that the kernel still needs to be patched to work with the current userspace utils. When I run the parser it complains that

Cache read/write disabled: /sys/kernel/security/apparmor/features interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
./apparmor_parser: cannot use or update cache, disable, or force-complain via stdin

The release notes from the utils v2.5 (https://apparmor.wiki.kernel.org/index.php/ReleaseNotes_2_5) talk about requiring a v2.4 compatibility patch for the kernel. I eventually found it at http://kernel.org/pub/linux/security/apparmor/apparmor-2.6.36-patches.tgz I think only the second patch is essential but have not had chance to apply them yet.

To get the user utils to compile I had to edit the Makefiles to set the correct paths; in common/Make.rules
POD2MAN = /usr/lib/perl5/core_perl/bin/pod2man
POD2HTML = /usr/lib/perl5/core_perl/bin/pod2html
in parser/tst/Makefile
PROVE=/usr/lib/perl5/core_perl/bin/prove
They will compile without rpm. One may need to change PERLPATH in the utils/Makefile as well for installation. To install do
make DESTDIR=$pkgdir install
I compiled the library, utils and parser only. I was messing around by hand so do not have a PKGBUILD. I'm not going to have anymore time to play on this for a while so if someone else tries the patch, please let us know if it solves the problem.

The good news is that without any profiles loaded all my programs behaved normally so enabling it in the official arch kernel may well be possible. The fact that the kernel appears to need to be patched to load profiles with the current utils is a real pain.

harvie: I think separate packages for profiles are an excellent idea. For something like firefox different people will want different trade-offs between security and ease of use (e.g. write permission only to a designated downloads directory or to a range of directories) and different profile packages would easily allow this.
Comment by Phillip Wood (phil) - Sunday, 24 October 2010, 19:08 GMT
[EDIT] Patches are not needed to load, reload or remove profiles, they are only needed for network confinement and some of the other tools [/EDIT]

Just found this page on the wiki which explains the need for patches
https://apparmor.wiki.kernel.org/index.php/Gittutorial
I wish they had a better index on the wiki.
Further to my notes above the initscripts in the parser directory will need hacking for arch and the Makefile ammending accordingly. Make DESTDIR=$pkgdir install needs to be executed in each first level sub directory below apparmor-2.5.1.
Comment by Tomas Mudrunka (harvie) - Sunday, 24 October 2010, 20:31 GMT
phil: Can't we just get version of userspace tools that is compatible with vanilla kernel?
BTW thx4info... :-)
Comment by Vlad George (DonVla) - Sunday, 24 October 2010, 20:49 GMT
Actually, I see no problem here.
I run a self-compiled kernel with apparmor option set (but disabled by default) and it runs just fine.
Sure, to use apparmor one needs the userspace tools, but this has nothing to do with the kernel option itself.
Comment by Tomas Mudrunka (harvie) - Sunday, 24 October 2010, 23:28 GMT
So brain0, phil, DonVla (and me) agreed that compiling kernel with AA will break nothing, so i guess it can be enabled in new kernel which will go to [testing], so we will be able get some potentional response (bug reports, general gripe, etc...) from other people until it will get moved to [core].

DonVla: Actually i think it should break nothing even with apparmor really enabled (until you start loading profiles). Can you please test booting kernel with security=apparmor parameter in grub? I guess it will change nothing at all... i believe that the option for disabling apparmor is only for cases where you want to use selinux or when there is some bug in your profiles or apparmor itself and you need some workaround. (anyway there is no reason for enabling it by default in distribution kernel and i just wonder if that works)
Comment by Linas (Linas) - Monday, 25 October 2010, 08:43 GMT
Ubuntu has an AppArmor profiles bundle package, but it is intended just for profile testing, with them in complain mode. When they are deemed stable, they are moved to the application package itself. See https://wiki.ubuntu.com/ApparmorProfileMigration
Comment by Phillip Wood (phil) - Monday, 25 October 2010, 09:05 GMT
[EDIT] The tools do infact work with the vanilla kernel. Kernel patches are not needed to load, reload or remove profiles, they are only needed for network confinement and some of the other tools [/EDIT]

Harvie - I don't think there is a stable release of the tools that works with the vanilla kernel see my link above. I'm happy to be proved wrong but the bundle pointed to from the wiki doesn't work with it. We would have to patch the kernel to get a useable version of AppArmor with these tools :-(
Comment by Thomas Bächler (brain0) - Monday, 25 October 2010, 09:28 GMT
So, is the version included in 2.6.36 too new or too old for the current stable userspace tools?
Comment by Phillip Wood (phil) - Monday, 25 October 2010, 13:57 GMT
[EDIT] Infact profile loading does work with v2.5.1&v2.6, see comment below [/EDIT]

brain0 - not sure which, maybe just incomplete, the wiki says it is missing the introspection interface needed by the tools. It is also missing the ability to confine network connections without the patches so the vanilla kernel cannot stop a rouge app accessing the network through a port you left open for another program. Just tried the 2.6 development branch of the tools but the parser seems to have the same problem.
Comment by Thomas Bächler (brain0) - Monday, 25 October 2010, 14:27 GMT
If AppArmor is not usable right now, I would wait to include it until 2.6.37 instead of patching it now. It's no use including something that is not usable for us.
Comment by Phillip Wood (phil) - Monday, 25 October 2010, 15:40 GMT
Humble apologies, it seems I was wrong, I had miss-read the wiki, was put off by the error messages and was using the parser wrongly! The user space utils will load policies but moan about the missing interfaces anyway. If in the profiles/apparmor.d directory I do

$ touch local/bin.ping
$ sudo ../../parser/apparmor_parser --base . bin.ping
Cache read/write disabled: /sys/kernel/security/apparmor/features interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
Warning from bin.ping (bin.ping line 28): profile /bin/ping network rules not enforced
$ sudo ../../parser/apparmor_parser --base . -R bin.ping
Cache read/write disabled: /sys/kernel/security/apparmor/features interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)

Then my logs show
Oct 25 16:19:32 localhost kernel: type=1400 audit(1288019972.990:2): apparmor="STATUS" operation="profile_load" name="/bin/ping" pid=3033 comm="apparmor_parser"
Oct 25 16:31:08 localhost kernel: type=1400 audit(1288020668.171:8): apparmor="STATUS" operation="profile_remove" name="/bin/ping" pid=3201 comm="apparmor_parser"

So it seems to work:-)
Having reread the wiki network restrictions will not work without the patch and some of the functionality of the scripts is lost but the basics do work so it is worth enabling it in the kernel after all.

Sorry for the confusion

Phil
Comment by Tomas Mudrunka (harvie) - Monday, 25 October 2010, 20:28 GMT
brain0: when it's good enough to be in stable vanilla kernel it can be good enough for us. maybe there are some features missing, but i believe that it's already able to restrict access to filesystem for specific applications in very usefull manner. But i don't see a reason why the others features should not be in that release. I think we are bit confused, because many of us never tried to configure apparmor on any system and we should learn how to do that. It will take some time to investigate how we should implement userspace tools in archlinux and sooner we start with research the sooner we'll be able to present some usable and secure solution capable of being installed on our servers (and other machines).
Comment by Tobias Powalowski (tpowa) - Monday, 25 October 2010, 20:36 GMT
It will be included in .36 with default to not use it.

Loading...