Ticket #1730 (closed enhancement: wontfix)

Opened 11 years ago

Last modified 10 years ago

SELinux Kernel Support

Reported by: willis Owned by: openmoko-kernel
Priority: normal Milestone:
Component: kernel Version:
Severity: normal Keywords: selinux, kernel
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

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.

Attachments

defconfig-2.6.24-selinux (40.5 KB) - added by willis 11 years ago.
2.6.24-selinux-kernel-config

Change History

Changed 11 years ago by willis

2.6.24-selinux-kernel-config

comment:1 Changed 11 years ago by willis

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

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

comment:2 Changed 11 years ago by 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?

comment:3 in reply to: ↑ description Changed 11 years ago by 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.

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by alphaone

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

comment:7 Changed 11 years ago by 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.

comment:8 Changed 11 years ago by 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?

comment:9 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by 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?

comment:11 Changed 11 years ago by willis

That works for me right now. Thank you.

comment:12 Changed 10 years ago by PaulFertser

  • Status changed from new to closed
  • HasPatchForReview unset
  • Resolution set to wontfix

Please reopen if still interested.

Note: See TracTickets for help on using tickets.