enforcement and initrds

enforcement and initrds

[Colin Walters]

Hi,

I'm having trouble booting up my SE 2.5 system in enforcing mode,
because my initrd (which uses ramfs) is completely unlabelled (because
ramfs doesn't support xattrs).  

When I add enforcing=1 to the Linux command line, it therefore dies
almost immediately upon bootup.  Perhaps it would be better to have the
kernel not do anything with the enforcing=1 commandline, but instead
have special code on the initrd to look at /proc/cmdline and if
necessary set enforcing mode right before booting init?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: enforcement and initrds

[Stephen Smalley]

On Sun, 2003-07-13 at 23:03, Colin Walters wrote:
> Hi,
> 
> I'm having trouble booting up my SE 2.5 system in enforcing mode,
> because my initrd (which uses ramfs) is completely unlabelled (because
> ramfs doesn't support xattrs).  
> 
> When I add enforcing=1 to the Linux command line, it therefore dies
> almost immediately upon bootup.  Perhaps it would be better to have the
> kernel not do anything with the enforcing=1 commandline, but instead
> have special code on the initrd to look at /proc/cmdline and if
> necessary set enforcing mode right before booting init?

If CONFIG_SECURITY_SELINUX_DEVELOP=n, then the kernel is always in
enforcing mode, so you won't be able to defer setting enforcing mode to
the initrd.  You can assign a single type to all of the ramfs entries
via genfs_contexts (but nothing more granular without further support
either in the ramfs code or in the SELinux module) and then grant
permissions to it.  Or you can grant permissions to unlabeled_t to
permit booting.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: enforcement and initrds

[Colin Walters]

On Mon, 2003-07-14 at 08:33, Stephen Smalley wrote:

> If CONFIG_SECURITY_SELINUX_DEVELOP=n, then the kernel is always in
> enforcing mode, so you won't be able to defer setting enforcing mode to
> the initrd. 

That's a good point, but then again we could just make DEVELOP=n instead
mean that once enforcing mode was switched on, it couldn't be switched
off.

>  You can assign a single type to all of the ramfs entries
> via genfs_contexts (but nothing more granular without further support
> either in the ramfs code or in the SELinux module) and then grant
> permissions to it. 

I tried this, but there appears to be a bootstrapping problem; the
policy says that romfs uses genfs; but the policy has to be loaded from
the initrd, which isn't labeled until we know what the policy is.

>  Or you can grant permissions to unlabeled_t to
> permit booting.

How?  Again that's part of the policy, so we face the same bootstrapping
problem.  

One other alternative would be to make kernel_t (SECINITSID_KERNEL) a
special SID that can do anything.  Anything with that type is a kernel
thread anyways, right?  So it could really do anything.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: enforcement and initrds

[Russell Coker]

On Tue, 15 Jul 2003 06:31, Colin Walters wrote:
> On Mon, 2003-07-14 at 08:33, Stephen Smalley wrote:
> > If CONFIG_SECURITY_SELINUX_DEVELOP=n, then the kernel is always in
> > enforcing mode, so you won't be able to defer setting enforcing mode to
> > the initrd.
>
> That's a good point, but then again we could just make DEVELOP=n instead
> mean that once enforcing mode was switched on, it couldn't be switched
> off.

You could compile with DEVELOP=y and use policy that prevents turning it off 
which is almost as good (anyone who can load a policy that allows turning it 
off can load a policy that permits everything).

> >  You can assign a single type to all of the ramfs entries
> > via genfs_contexts (but nothing more granular without further support
> > either in the ramfs code or in the SELinux module) and then grant
> > permissions to it.
>
> I tried this, but there appears to be a bootstrapping problem; the
> policy says that romfs uses genfs; but the policy has to be loaded from
> the initrd, which isn't labeled until we know what the policy is.

Last time I did this it worked OK, SE Linux loaded the policy as part of the 
mount process.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: enforcement and initrds

[Colin Walters]

On Mon, 2003-07-14 at 17:33, Russell Coker wrote:

> You could compile with DEVELOP=y and use policy that prevents turning it off 
> which is almost as good (anyone who can load a policy that allows turning it 
> off can load a policy that permits everything).

True enough.

> Last time I did this it worked OK, SE Linux loaded the policy as part of the 
> mount process.

In 2.5 that doesn't happen anymore, which I think is good.  Hardcoding
stuff like /etc/security inside Linux is just a bad idea.  But we have
to figure out exactly how the initrd should work.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: enforcement and initrds

[Stephen Smalley]

On Mon, 2003-07-14 at 16:31, Colin Walters wrote:
> That's a good point, but then again we could just make DEVELOP=n instead
> mean that once enforcing mode was switched on, it couldn't be switched
> off.

I'd prefer to be able to compile out the permissive mode support
entirely for production kernels.

> I tried this, but there appears to be a bootstrapping problem; the
> policy says that romfs uses genfs; but the policy has to be loaded from
> the initrd, which isn't labeled until we know what the policy is.

romfs or ramfs?  It isn't an issue whether it is labeled before the
policy is loaded; all permission checks are allowed until the policy is
loaded and the security server is initialized.  At some point, we'd like
to generate an initial bootstrapping policy that is built into the
security server, but there isn't any point in doing that until things
stabilize a bit more, and that initial policy could be dependent on your
particular kernel configuration and your initrd setup.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[patch] Re: enforcement and initrds

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

On Tue, 2003-07-15 at 13:15, Stephen Smalley wrote:
> On Mon, 2003-07-14 at 16:31, Colin Walters wrote:
> > That's a good point, but then again we could just make DEVELOP=n instead
> > mean that once enforcing mode was switched on, it couldn't be switched
> > off.
> 
> I'd prefer to be able to compile out the permissive mode support
> entirely for production kernels.

I can understand that.

> romfs or ramfs?  

romfs, sorry about my initial misstatement.

> It isn't an issue whether it is labeled before the
> policy is loaded; all permission checks are allowed until the policy is
> loaded and the security server is initialized.  

Ahh, I see.  Ok.  

I've created an initrd.te which appears to work for me.  I put it in
types/initrd.te.

> At some point, we'd like
> to generate an initial bootstrapping policy that is built into the
> security server, but there isn't any point in doing that until things
> stabilize a bit more, and that initial policy could be dependent on your
> particular kernel configuration and your initrd setup.

Yeah...I think this initrd.te is a first step towards that bootstrapping
policy.


[-- Attachment #2: initrd.te --]
[-- Type: text/plain, Size: 659 bytes --]

#
# Description: allow ramfs/cramfs initrd bootstrapping from unlabeled_t
# Authors: Colin Walters <walters@verbum.org>

# Operate on unlabeled files.
allow kernel_t unlabeled_t:file_class_set create_file_perms;
allow kernel_t unlabeled_t:dir create_dir_perms;
# Allow running scripts and such on the initrd.
can_exec(kernel_t, unlabeled_t);

# Mount permissions, stolen from mount.te
allow kernel_t unlabeled_t:filesystem mount_fs_perms;
allow kernel_t unlabeled_t:dir mounton;
allow kernel_t proc_t:dir mounton;

# Operate on tmpfs.
allow kernel_t tmpfs_t:file_class_set create_file_perms;
allow kernel_t tmpfs_t:dir create_dir_perms;