selinux cramfs

selinux cramfs

[Debian User]

how do we make selinux work on cramfs?


--
You have received this message because you are subscribed to the selinux 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: selinux cramfs

[Russell Coker]

On Fri, 21 Jun 2002 06:48, Debian User wrote:
> how do we make selinux work on cramfs?

To have full support for a file system (as with Ext2, Ext3, and ReiserFS) you 
need to have persistant Inode numbers, and the Inode numbers need to be known 
by the kernel (or setfiles) some time after the files were created.

This is not possible on cramfs.

The solution for a cramfs initrd is to have CONFIG_SECURITY_SELINUX_DEVELOP=y 
in your kernel config and then use avc_toggle to enable enforcing mode in 
your init scripts.  Then you get some avc errors at boot up from your cramfs 
but it's not a big deal.

Another option is to use ext2 for an initrd.

A final option is to compile your kernel such that an initrd is not needed, 
but that is not possible for a cryptoapi root file system...

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--
You have received this message because you are subscribed to the selinux 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: selinux cramfs

[Debian User]

Russell Coker wrote:

>On Fri, 21 Jun 2002 06:48, Debian User wrote:
>
>>how do we make selinux work on cramfs?
>>
>
>To have full support for a file system (as with Ext2, Ext3, and ReiserFS) you 
>need to have persistant Inode numbers, and the Inode numbers need to be known 
>by the kernel (or setfiles) some time after the files were created.
>
>This is not possible on cramfs.
>
Hmm this might explain why everything has the unlabeled context when I 
run my system.

>
>
>The solution for a cramfs initrd is to have CONFIG_SECURITY_SELINUX_DEVELOP=y 
>in your kernel config and then use avc_toggle to enable enforcing mode in 
>your init scripts.  Then you get some avc errors at boot up from your cramfs 
>but it's not a big deal.
>
>Another option is to use ext2 for an initrd.
>
>A final option is to compile your kernel such that an initrd is not needed, 
>but that is not possible for a cryptoapi root file system...
>
Im using cramfs for a read only root filesystem.
How does selinux do the labeling then? Is it just an integer associated 
with inodes? Maybe I have to read the white papers all over again.


--
You have received this message because you are subscribed to the selinux 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: selinux cramfs

[Stephen Smalley]

On Fri, 21 Jun 2002, Debian User wrote:

> Im using cramfs for a read only root filesystem.
> How does selinux do the labeling then? Is it just an integer associated
> with inodes? Maybe I have to read the white papers all over again.

The SELinux module only tries to assign labels to filesystem types that
are known to be supported.  We've made the labeling behavior more
configurable and general since the last release, but that won't help
with your particular problem.  SELinux uses one of four approaches to
label inodes in the filesystem, based on the filesystem type, plus some
specialized logic for /proc/PID and /proc/sys.  Any unrecognized
filesystem types are left with the unlabeled SID and its corresponding
context.

The four approaches are:

1) Use a persistent label mapping.  This is appropriate for filesystems
that have unique and persistent inode numbers.  A two-level mapping is
maintained in each filesystem between inode numbers and integer PSIDs and
between PSIDs and security contexts.  The mapping is typically initialized
via setfiles, although the kernel will try to automatically initialize the
mapping to a minimal state if a filesystem is mounted that lacks any
mapping.  SELinux uses this approach for ext2, ext3, and reiserfs, and
it should also work for alternate filesystems like XFS.  If extended
attributes become widely available in filesystems, then SELinux will
likely be retargeted to take advantage of them for this purpose.

2) Use the allocating task SID.  This is appropriate for the pipefs and
sockfs pseudo filesystems, where we want the pipes and sockets to be
labeled with the SID of the allocating task (the kind of object in this
case is implicit from the security class).

3) Use a transition SID computed from the allocating task SID and the
filesystem SID.  This is appropriate for the devpts and tmpfs pseudo
filesystems, where we want the inodes to be labeled with a SID that
expresses information about both the allocating task and the kind of
object being represented (i.e. is it a pty, a shared memory object, etc?).

4) Use a context obtained from a configuration based on filesystem
type, pathname prefix matching and file type.  This is appropriate for
pseudo filesystems like proc (outside of /proc/PID and /proc/sys), devfs,
usbdevfs, and driverfs.  In the current release, this is only done for
devfs, with hardcoded logic for proc and usbdevfs, but we have
subsequently generalized the mechanism so that it can be applied to other
filesystem types.

Specialized logic in the module ensures that the /proc/PID entries are
labeled with the SID of the associated task and that the /proc/sys entries
are labeled with the SID of the corresponding sysctl variable.

You might be able to handle cramfs to some degree using the new
genfs_contexts configuration, which is a generalization of devfs_contexts.
That isn't in the current release, but will be in the next one.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: selinux cramfs

[Stephen Smalley]

On Fri, 21 Jun 2002, Stephen Smalley wrote:

> You might be able to handle cramfs to some degree using the new
> genfs_contexts configuration, which is a generalization of devfs_contexts.
> That isn't in the current release, but will be in the next one.

I just tried using genfs_contexts to specify a context for cramfs and
then mounting a cramfs image, and it appears to work correctly.  So this
will hopefully be addressed by the next public release.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: selinux cramfs

[Debian User]

Great! I was planning to hack away already.

Stephen Smalley wrote:

>On Fri, 21 Jun 2002, Stephen Smalley wrote:
>
>>You might be able to handle cramfs to some degree using the new
>>genfs_contexts configuration, which is a generalization of devfs_contexts.
>>That isn't in the current release, but will be in the next one.
>>
>
>I just tried using genfs_contexts to specify a context for cramfs and
>then mounting a cramfs image, and it appears to work correctly.  So this
>will hopefully be addressed by the next public release.
>
>--
>Stephen D. Smalley, NAI Labs
>ssmalley@nai.com
>
>




--
You have received this message because you are subscribed to the selinux 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: selinux cramfs

[Russell Coker]

On Fri, 21 Jun 2002 14:45, Stephen Smalley wrote:
> On Fri, 21 Jun 2002, Stephen Smalley wrote:
> > You might be able to handle cramfs to some degree using the new
> > genfs_contexts configuration, which is a generalization of
> > devfs_contexts. That isn't in the current release, but will be in the
> > next one.
>
> I just tried using genfs_contexts to specify a context for cramfs and
> then mounting a cramfs image, and it appears to work correctly.  So this
> will hopefully be addressed by the next public release.

Excellent!

Howard, when is the next release scheduled?


Stephen,  I'm just about to test those patches you sent me.



Russell Coker

--
You have received this message because you are subscribed to the selinux 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: selinux cramfs

[Debian User]

Russell Coker wrote:

>On Fri, 21 Jun 2002 14:45, Stephen Smalley wrote:
>
>>On Fri, 21 Jun 2002, Stephen Smalley wrote:
>>
>>>You might be able to handle cramfs to some degree using the new
>>>genfs_contexts configuration, which is a generalization of
>>>devfs_contexts. That isn't in the current release, but will be in the
>>>next one.
>>>
>>I just tried using genfs_contexts to specify a context for cramfs and
>>then mounting a cramfs image, and it appears to work correctly.  So this
>>will hopefully be addressed by the next public release.
>>
>
>Excellent!
>
>Howard, when is the next release scheduled?
>
>
>Stephen,  I'm just about to test those patches you sent me.
>
>
>
>Russell Coker
>
Cool! My system is waiting. Lots of possibilities here.



--
You have received this message because you are subscribed to the selinux 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: selinux cramfs

[Russell Coker]

On Fri, 21 Jun 2002 13:49, Debian User wrote:
> >A final option is to compile your kernel such that an initrd is not
> > needed, but that is not possible for a cryptoapi root file system...
>
> Im using cramfs for a read only root filesystem.
> How does selinux do the labeling then? Is it just an integer associated
> with inodes? Maybe I have to read the white papers all over again.

It basically ends up as an integer associated with each Inode.

SE Linux in it's current form can't work with a root file system such as 
cramfs or NFS.

You can use ext2 in a ram disk mounted read-only for a read-only root file 
system.  Or you could use Ext2 with compression patches and a read-only block 
device to get the same results as you seem to be aiming for (compression and 
impossibility of writing).

Of course if unix permissions and SE permissions both fail and someone gets 
access to /dev/kmem then nothing will save you...

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--
You have received this message because you are subscribed to the selinux 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.