MCS policy patch

MCS policy patch

[Russell Coker]

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

The attached patch makes MCS a discretionary policy instead of being an 
advisory policy as it is at the moment.  This denies a process the ability to 
launch, kill, or ptrace a process unless it's level dominates that of the 
target process.  Also the same restriction is placed on creation and 
relabelto for files, directories etc.

It still doesn't place any MCS restrictions on read/write for file system 
objects other than files, but allowing for example a process to create a 
directory in a context that it could not relabel a directory to or from is 
bogus.

Also my patch denies the ability to create file system objects with ranges.  
We have no way of using such ranges so I believe that we don't want them 
created.  They are at best a waste of space and at worst allow programs to 
perform in ways that will be unexpected when used by people who don't 
understand them (better to give an error message than have the system give a 
result that the user doesn't expect when they do the wrong thing).

Dan, is it too late for this to be in FC5T3?  I've intentionally removed all 
the bits that are complex or likely to cause breakage from this patch to 
allow it to be included...


Also this patch adds a new type usb_device_t, bluetooth.te needs policy to 
access it, but I don't have time to write it before sending this patch.

-- 
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

[-- Attachment #2: pol3.diff --]
[-- Type: text/x-diff, Size: 3472 bytes --]

diff -ru serefpolicy-2.2.9.orig/policy/mcs serefpolicy-2.2.9/policy/mcs
--- serefpolicy-2.2.9.orig/policy/mcs	2006-01-31 10:41:22.000000000 +1100
+++ serefpolicy-2.2.9/policy/mcs	2006-02-04 00:47:25.000000000 +1100
@@ -137,15 +137,28 @@
 # Only files are constrained by MCS at this stage.
 #
 mlsconstrain file { write setattr append unlink link rename
-		    create ioctl lock execute } (h1 dom h2);
+		    ioctl lock execute relabelfrom } (h1 dom h2);
+
+mlsconstrain file { create relabelto } ((h1 dom h2) and (l2 eq h2));
 
 mlsconstrain file { read } ((h1 dom h2) or 
 			    ( t1 == mlsfileread ));
 
 
 # new file labels must be dominated by the relabeling subject clearance
-mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { relabelfrom relabelto }
+mlsconstrain { dir lnk_file chr_file blk_file sock_file fifo_file } { relabelfrom }
 	( h1 dom h2 );
+mlsconstrain { dir lnk_file chr_file blk_file sock_file fifo_file } { create relabelto }
+	(( h1 dom h2 ) and ( l2 eq h2 ));
+
+mlsconstrain process { ptrace } ( h1 dom h2 );
+
+mlsconstrain process { transition dyntransition } (( h1 dom h2 ) or
+		( t1 == getty_t ) or ( t1 == init_t ) or ( t1 == initrc_t ) or
+		( t1 == kernel_t ));
+
+mlsconstrain process { sigkill sigstop signal } ( h1 dom h2 ) or
+		( t1 == init_t ) or ( t1 == initrc_t );
 
 define(`nogetattr_file_perms', `{ create ioctl read lock write setattr append 
 link unlink rename relabelfrom relabelto }')
diff -ru serefpolicy-2.2.9.orig/policy/modules/admin/kudzu.te serefpolicy-2.2.9/policy/modules/admin/kudzu.te
--- serefpolicy-2.2.9.orig/policy/modules/admin/kudzu.te	2006-01-31 10:41:23.000000000 +1100
+++ serefpolicy-2.2.9/policy/modules/admin/kudzu.te	2006-02-04 00:21:13.000000000 +1100
@@ -24,7 +24,6 @@
 allow kudzu_t self:capability { dac_override sys_admin sys_rawio net_admin sys_tty_config mknod };
 dontaudit kudzu_t self:capability sys_tty_config;
 allow kudzu_t self:process { signal_perms execmem };
-auditallow kudzu_t self:process execmem; 
 allow kudzu_t self:fifo_file rw_file_perms;
 allow kudzu_t self:unix_stream_socket { connectto create_stream_socket_perms };
 allow kudzu_t self:unix_dgram_socket create_socket_perms;
diff -ru serefpolicy-2.2.9.orig/policy/modules/kernel/devices.fc serefpolicy-2.2.9/policy/modules/kernel/devices.fc
--- serefpolicy-2.2.9.orig/policy/modules/kernel/devices.fc	2006-01-31 10:41:23.000000000 +1100
+++ serefpolicy-2.2.9/policy/modules/kernel/devices.fc	2006-02-04 00:59:07.000000000 +1100
@@ -78,6 +78,7 @@
 /dev/usb/lp.*		-c	gen_context(system_u:object_r:printer_device_t,s0)
 /dev/usb/mdc800.*	-c	gen_context(system_u:object_r:scanner_device_t,s0)
 /dev/usb/scanner.*	-c	gen_context(system_u:object_r:scanner_device_t,s0)
+/dev/bus/usb/.*/[0-9]+	-c	gen_context(system_u:object_r:usb_device_t,s0)
 
 ifdef(`distro_redhat',`
 # originally from named.fc
diff -ru serefpolicy-2.2.9.orig/policy/modules/kernel/devices.te serefpolicy-2.2.9/policy/modules/kernel/devices.te
--- serefpolicy-2.2.9.orig/policy/modules/kernel/devices.te	2006-01-31 10:41:23.000000000 +1100
+++ serefpolicy-2.2.9/policy/modules/kernel/devices.te	2006-02-04 01:00:44.000000000 +1100
@@ -159,6 +159,11 @@
 genfscon usbfs / gen_context(system_u:object_r:usbfs_t,s0)
 genfscon usbdevfs / gen_context(system_u:object_r:usbfs_t,s0)
 
+#
+# usb_device_t is the type for /dev/bus/usb/[0-9]+/[0-9]+
+type usb_device_t;
+dev_node(usb_device_t)
+
 type v4l_device_t;
 dev_node(v4l_device_t)
 

Re: MCS policy patch

[James Morris]

On Sat, 4 Feb 2006, Russell Coker wrote:

> The attached patch makes MCS a discretionary policy instead of being an 
> advisory policy as it is at the moment.  This denies a process the ability to 
> launch, kill, or ptrace a process unless it's level dominates that of the 
> target process.  

Ok, I think this makes sense, to stop a malicious process from launching a 
program at a higher level to bypass the category restrictions.  However, 
it raises the question of whether we have all such channels locked down.

Also, do we need dynamic transitions at all in MCS?

> Also the same restriction is placed on creation and relabelto for files, 
> directories etc.

I thought we already had this.

> It still doesn't place any MCS restrictions on read/write for file system 
> objects other than files, but allowing for example a process to create a 
> directory in a context that it could not relabel a directory to or from is 
> bogus.

I'm still not sure what the best model is for directories.  I've had a 
couple of people email and say they want files created under an MCS 
labeled directory to inherit the label.

I like the idea of keeping things as absolutely as simple as possible, and 
leaving MCS as a user-oriented discretionary tool, where the end user (and 
not the admin) is responsible for labeling all of their own files 
indivdually.

> Also my patch denies the ability to create file system objects with ranges.  
> We have no way of using such ranges so I believe that we don't want them 
> created.

Yep, they are pointless in MCS.

> Dan, is it too late for this to be in FC5T3?  I've intentionally removed all 
> the bits that are complex or likely to cause breakage from this patch to 
> allow it to be included...

It looks ok to me, but I'd appreciate any further review.


- James
-- 
James Morris
<jmorris@namei.org>

--
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: MCS policy patch

[Russell Coker]

On Saturday 04 February 2006 06:31, James Morris <jmorris@namei.org> wrote:
> Also, do we need dynamic transitions at all in MCS?

We aren't using them yet in any other policy, but it seemed correct to add the 
constraint as I did.  Of course we could just force the dynamic transition to 
stay at the same level.

> > Also the same restriction is placed on creation and relabelto for files,
> > directories etc.
>
> I thought we already had this.

For relabelto yes, but not for creation.  Therefore it was possible to create 
objects that you could not relabel.

> > It still doesn't place any MCS restrictions on read/write for file system
> > objects other than files, but allowing for example a process to create a
> > directory in a context that it could not relabel a directory to or from
> > is bogus.
>
> I'm still not sure what the best model is for directories.  I've had a
> couple of people email and say they want files created under an MCS
> labeled directory to inherit the label.

Is it even possible to do that without kernel code changes?  Currently it 
seems that the limit in this regard is the low level of the process.

Also I think we want to go slowly on this and preserve the "targeted" design 
goal of breaking as few things as possible.  We can (and will) add further 
constraints at later times.

> I like the idea of keeping things as absolutely as simple as possible, and
> leaving MCS as a user-oriented discretionary tool, where the end user (and
> not the admin) is responsible for labeling all of their own files
> indivdually.

I agree.

-- 
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: MCS policy patch

[Daniel J Walsh]

+
+mlsconstrain process { transition dyntransition } (( h1 dom h2 ) or
+		( t1 == getty_t ) or ( t1 == init_t ) or ( t1 == initrc_t ) or
+		( t1 == kernel_t ));
+

This does not work currently because it will not allow unconfined_t to run /bin/su if unconfined_t is not set to SystemLow->SystemHigh.


--
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: MCS policy patch

[Christopher J. PeBenito]

On Sat, 2006-02-04 at 01:18 +1100, Russell Coker wrote:
> +mlsconstrain process { transition dyntransition } (( h1 dom h2 ) or
> +               ( t1 == getty_t ) or ( t1 == init_t ) or ( t1 == initrc_t ) or
> +               ( t1 == kernel_t ));
> +
> +mlsconstrain process { sigkill sigstop signal } ( h1 dom h2 ) or
> +               ( t1 == init_t ) or ( t1 == initrc_t );

We can't have these hardcoded types.  What we need is similar to how the
mls constraints are handled.  Attributes and interfaces need to be added
to the mls module, then the above domains would use the interfaces to
gain these attributes.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: MCS policy patch

[Russell Coker]

On Tuesday 07 February 2006 10:04, "Christopher J. PeBenito" 
<cpebenito@tresys.com> wrote:
> On Sat, 2006-02-04 at 01:18 +1100, Russell Coker wrote:
> > +mlsconstrain process { transition dyntransition } (( h1 dom h2 ) or
> > +               ( t1 == getty_t ) or ( t1 == init_t ) or ( t1 == initrc_t
> > ) or +               ( t1 == kernel_t ));
> > +
> > +mlsconstrain process { sigkill sigstop signal } ( h1 dom h2 ) or
> > +               ( t1 == init_t ) or ( t1 == initrc_t );
>
> We can't have these hardcoded types.  What we need is similar to how the
> mls constraints are handled.  Attributes and interfaces need to be added
> to the mls module, then the above domains would use the interfaces to
> gain these attributes.

Actually I never planned to have it like that.  But the lack of support for 
range transition statements outside the base module prevents me from doing 
what I want.

I believe that the correct thing to do is to have kernel processes run with 
context s0:c0.c255, and have init scripts or daemons transition to 
s0-s0:c0.c255 or s0 as appropriate.  Therefore neither of the above 
statements would have any of the exceptions that are listed.

Adding attributes for things that we plan to remove is not desirable IMHO.  
Although I admit that it's likely that we won't get it all working the way we 
like before FC5 release and having the policy you quote above in FC5 would 
suck a little.

RHEL5 can't be released with the above policy, not because it's an enterprise 
product, but because it'll be around for 7 years...

-- 
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: MCS policy patch

[Russell Coker]

My previous message was unclear.

On Tuesday 07 February 2006 14:19, Russell Coker <russell@coker.com.au> wrote:
> > We can't have these hardcoded types.  What we need is similar to how the
> > mls constraints are handled.  Attributes and interfaces need to be added
> > to the mls module, then the above domains would use the interfaces to
> > gain these attributes.
>
> Actually I never planned to have it like that.  But the lack of support for
> range transition statements outside the base module prevents me from doing
> what I want.

What I want to do is to have the init scripts run at SystemHigh and have a 
range transition for every daemon that doesn't need such access (most 
daemons), doing this without range_transition in all modules would be a gross 
hack.  Also I am considering having some daemons such as Postfix run with 
some processes at SystemHigh and some at s0.

Another thing, I think that a default user login should not have SystemHigh, 
maybe s0:c0.c127.  The reason is that the administrator will add accounts, 
have a running system with files labelled on disk and in backup storage, and 
THEN they will decide that they want one particular account to have more 
access than the default.  This will be a major PITA if every account already 
has all the categories.  If we make the default level be s0:c0.c127 then that 
still gives plenty of levels to choose from (it shouldn't restrict real use 
of the system) and it allows adding new users with more access than the 
default.

This one only just occurred to me, but it's something that I think is quite 
important to be in FC5T3 to avoid the current situation propagating too far.

-- 
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: MCS policy patch

[Daniel J Walsh]

Russell Coker wrote:
> My previous message was unclear.
>
> On Tuesday 07 February 2006 14:19, Russell Coker <russell@coker.com.au> wrote:
>   
>>> We can't have these hardcoded types.  What we need is similar to how the
>>> mls constraints are handled.  Attributes and interfaces need to be added
>>> to the mls module, then the above domains would use the interfaces to
>>> gain these attributes.
>>>       
>> Actually I never planned to have it like that.  But the lack of support for
>> range transition statements outside the base module prevents me from doing
>> what I want.
>>     
>
> What I want to do is to have the init scripts run at SystemHigh and have a 
> range transition for every daemon that doesn't need such access (most 
> daemons), doing this without range_transition in all modules would be a gross 
> hack.  Also I am considering having some daemons such as Postfix run with 
> some processes at SystemHigh and some at s0.
>
> Another thing, I think that a default user login should not have SystemHigh, 
> maybe s0:c0.c127.  The reason is that the administrator will add accounts, 
> have a running system with files labelled on disk and in backup storage, and 
> THEN they will decide that they want one particular account to have more 
> access than the default.  This will be a major PITA if every account already 
> has all the categories.  If we make the default level be s0:c0.c127 then that 
> still gives plenty of levels to choose from (it shouldn't restrict real use 
> of the system) and it allows adding new users with more access than the 
> default.
>
> This one only just occurred to me, but it's something that I think is quite 
> important to be in FC5T3 to avoid the current situation propagating too far.
>
>   
Default users login with s0.  They have no categories.  This information 
is gathered  via the seusers interface.
If the admin wants to give a user access to categories he will need to 
use semanage to give this access.

By default all processes should run at s0, currently we have no way to 
change this level that a daemon will run at.
Correct?

--
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.