SELinux Kernel Support

[willis]

I am working on porting SELinux to OpenMoko? devices as a GSoC 2008 project. Currently distributed prebuilt kernel images do not support SELinux in the kernel. I propose support for SELinux in the kernel become standard.

I have attached a SELinux enabled 2.6.24 kernel .config and uImage for testing.

[willis]

2.6.24-selinux-kernel-config

[willis]

The uImage is larger than the maximum attachment size. It is mirrored here:

​http://selinux-openmoko.googlecode.com/svn/trunk/uImageSElinux_20080731

[andy]

Hi -

I use selinux on my normal boxes, but I wonder what is the story about what we can expect from selinux support given we did not take care about even user / group functional separation properly yet in our rootfs. Is there any practical example of why selinux on in kernel for all users would be a win?

[queen6]

Replying to willis:

I propose support for SELinux in the kernel become standard.

Not everyone wants and it's willing to use SELinux as default. _Personally_ I can't see a point of running SELinux on Neo.
I believe it should NOT be turned on by default. There might be a separate kernel image with SELinux enabled, but forcing people to use it, isn't the best idea.

[alphaone]

We are currently investigating how to secure the dbus communication. See the SELinux section in ​http://linux.die.net/man/1/dbus-daemon-1 for more details. I think SELinux support will become default once that is implemented correctly. After all you don't want a browser exploit to send masses of SMS.

[andy]

It sounds like something that's useful, but shouldn't we first make some users and groups for everything? I'm pretty sure the two layers of security together will work better than just depending on one.

[alphaone]

Sure, but adding a user wouldn't be an exciting GSoC project. :-)

[willis]

Adding SELinux support to the kernel doesn't force anyone to use SELinux, it just gives them an SELinux enabled kernel. SELinux can be kept off by default in the rootfs. When installed, the SELinux package would then install the policy and turn SELinux on. The trade-off with enabling it by default is that the kernel will be larger and boot slower. But if a user chooses to install SELinux then they will not be required to flash a new kernel image (which they would be required to do if not supported by default). I guess the discussion should be: would the number of users that would potentially use SELinux on their device support the decision of increasing kernel size/boot time? This seems like it would be dependent on how much kernel size/boot time increases which I'm not qualified to answer. Although if someone would be willing to do some testing on the uImage to get empirical data =) ...

I wonder what is the story about what we can expect from selinux support given we did not take > care about even user / group functional separation properly yet in our rootfs.

True, user/group defaults would go a ways towards increasing security on the device. But I think in the meantime (or in spite of this), SELinux on a single user device makes a lot of sense. In particular, the benefit of SELinux is that it can prevent privilege escalation between two root processes by sandboxing each.

[andy]

I don't mean user / group process separation is in competition with SELinux. I mean it is a bit of a bad sign if we just jumped on the strongest medicine and everything else inside takes no care about security.

Another thing about SELinux, I read that jffs2 can take the extended attributes, is the default format that we use for jffs2 image ready for this?

[stefan_schmidt]

The original question was if you could enable selinux in the defconfig.

I agree that there are more things to do for good SELinux support. Still we have a GSoC project running that uses selinux for a security policy for the dbus based framework services.

It would ease the developing if it would be enabled in the default config. Enabling it on build system level is also possible, but would lead to more config fragmentation IMHO.

[andy]

I am running around like a crazy man with ten different jobs at the moment, but I did in fact try this out here a few days ago. I enabled SELINUX but had it default to disabled, it did not cause any disruption I could see.

Recently I started creating "moredriver" kernel images and sticking them here:

​http://people.openmoko.org/andy/

these are built direct from defconfig-2.6.24 at the moment. How about for now I adapt defconfig-2.6.24 to support SELINUX but leave the distribution configs alone for now, then you can use kernel binaries from that dir. All the critical modules like sound / WLAN / Ethernet over USB are built-in, but there are no other funkier modules.

Is this moving you forward?

[willis]

That works for me right now. Thank you.

[PaulFertser]

Please reopen if still interested.