mdadm policy

mdadm policy

[antoine]

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

I was looking for a policy for mdadm, I know there is one in Fedora, but
I use gentoo and I couldn't download it without getting the whole rpm,
so I ended up writing one (attached) - it is also a good learning
exercise. Shouldn't it be in serefpolicy.sourceforge.net?

Works for me (tm)
Is this any good? (I think it should probably use macros for shlib and
ptys, and use dontaudit instead of allow for some of the devices)

Antoine

[-- Attachment #2: mdadm.fc --]
[-- Type: text/plain, Size: 102 bytes --]

/etc/mdadm.conf					--	system_u:object_r:mdadm_etc_t
/sbin/mdadm					--	system_u:object_r:mdadm_bin_t

[-- Attachment #3: mdadm.te --]
[-- Type: text/plain, Size: 1887 bytes --]

# antoine@nagafix.co.uk

daemon_domain(mdadm, `, fs_domain')

type mdadm_etc_t, file_type, sysadmfile;
type mdadm_bin_t, file_type, sysadmfile;

domain_auto_trans(initrc_t, mdadm_bin_t, mdadm_t)
domain_auto_trans(sysadm_t, mdadm_bin_t, mdadm_t)

# role system_r types mdadm_t;

allow initrc_t mdadm_etc_t:file read;
allow mdadm_t mdadm_etc_t:file { getattr read };

allow mdadm_t etc_t:dir search;

allow mdadm_t ld_so_cache_t:file { getattr read };
allow mdadm_t lib_t:dir search;
allow mdadm_t lib_t:lnk_file read;
allow mdadm_t shlib_t:file { execute getattr read };

allow mdadm_t proc_mdstat_t:file { getattr read };
allow mdadm_t proc_t:dir search;
allow mdadm_t root_t:dir search;

allow mdadm_t tmpfs_t:dir { getattr read };


allow mdadm_t device_t:lnk_file read;

allow mdadm_t self:capability sys_admin;


# DEV:
allow mdadm_t clock_device_t:chr_file getattr;
allow mdadm_t console_device_t:chr_file { getattr read write };
allow mdadm_t cpu_device_t:chr_file getattr;
allow mdadm_t device_t:blk_file { getattr ioctl read };
allow mdadm_t device_t:chr_file getattr;
allow mdadm_t device_t:dir { getattr read search };
allow mdadm_t device_t:file getattr;
allow mdadm_t device_t:lnk_file getattr;
allow mdadm_t devlog_t:sock_file getattr;
allow mdadm_t devpts_t:dir { getattr read };
allow mdadm_t devtty_t:chr_file getattr;
allow mdadm_t fixed_disk_device_t:blk_file getattr;
allow mdadm_t init_t:fd use;
allow mdadm_t initctl_t:fifo_file getattr;
allow mdadm_t memory_device_t:chr_file getattr;
allow mdadm_t mouse_device_t:chr_file getattr;
allow mdadm_t null_device_t:chr_file { getattr read };
allow mdadm_t ptmx_t:chr_file getattr;
allow mdadm_t random_device_t:chr_file getattr;
allow mdadm_t tty_device_t:chr_file getattr;
#allow mdadm_t tun_tap_device_t:chr_file getattr;
allow mdadm_t zero_device_t:chr_file getattr;

allow mdadm_t fixed_disk_device_t:blk_file read;

Re: mdadm policy

[Ivan Gyurdiev]

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

On Fri, 2005-06-24 at 00:27 +0100, antoine wrote:
> I was looking for a policy for mdadm, I know there is one in Fedora, but
> I use gentoo and I couldn't download it without getting the whole rpm,

Policy is attached, and I recommend using something similar
over the one you have.

> so I ended up writing one (attached) - it is also a good learning
> exercise. Shouldn't it be in serefpolicy.sourceforge.net?
> 
> Works for me (tm)

The following things are wrong with this policy:

(1) It allows everything the program wants to do, regardless
of whether it is a good idea.

(2) It is not organized in any sensible way. Sensible way means
making use of existing macros, grouping rules together,
and commenting *everything* with the purpose for adding
that rule (or better yet group of rules) - this is the
overall action that you want to allow with this block of rules.

(3) It adds primitive rules for things already present in macros.
For example, the daemon_domain covers the transition.

(4)...and there's numerous specific things wrong with it,
that I won't go into....starting from lack of exec_type on
the bin_type, not following naming conventions, etc..

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University

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

#DESC mdadm - Linux RAID tool
#
# Author: Colin Walters <walters@redhat.com>
#

daemon_base_domain(mdadm, `, fs_domain')
role sysadm_r types mdadm_t;

allow initrc_t mdadm_var_run_t:file create_file_perms;

# Kernel filesystem permissions
r_dir_file(mdadm_t, proc_t)
allow mdadm_t proc_mdstat_t:file rw_file_perms;
read_sysctl(mdadm_t)
r_dir_file(mdadm_t, sysfs_t) 

# Configuration
allow mdadm_t { etc_t etc_runtime_t }:file { getattr read };
read_locale(mdadm_t)

# Linux capabilities
allow mdadm_t self:capability { dac_override sys_admin ipc_lock };

# Helper program access
can_exec(mdadm_t, { bin_t sbin_t })

# RAID block device access
allow mdadm_t fixed_disk_device_t:blk_file create_file_perms;
allow mdadm_t device_t:lnk_file { getattr read };

# Ignore attempts to read every device file
dontaudit mdadm_t device_type:{ chr_file blk_file } getattr;
dontaudit mdadm_t device_t:{ fifo_file file dir chr_file blk_file } { read getattr };
dontaudit mdadm_t devpts_t:dir r_dir_perms;

# Ignore attempts to read/write sysadmin tty
dontaudit mdadm_t sysadm_tty_device_t:chr_file rw_file_perms;

# Other random ignores
dontaudit mdadm_t tmpfs_t:dir r_dir_perms;
dontaudit mdadm_t initctl_t:fifo_file getattr;
var_run_domain(mdadm)
allow mdadm_t var_t:dir { getattr search };

Re: mdadm policy

[antoine]

> (1) It allows everything the program wants to do, regardless
> of whether it is a good idea.
> > "I think it should probably use macros for shlib and
ptys, and use dontaudit instead of allow for some of the devices"
AFAIK, the only one I had missed in the statement above was the tmpfs.
I'll admit I was going to keep zero_device_t and a few others...

> (2) It is not organized in any sensible way. Sensible way means
> making use of existing macros, grouping rules together,
> and commenting *everything* with the purpose for adding
> that rule (or better yet group of rules) - this is the
> overall action that you want to allow with this block of rules.
As above. Once the devices are gone and you use macros where possible,
it kind of organises itself.

> (3) It adds primitive rules for things already present in macros.
> For example, the daemon_domain covers the transition.
Missed that little one, thanks. (no harm done)

> (4)...and there's numerous specific things wrong with it,
Numerous? That covers pretty much everything already! It isn't that big
> that I won't go into....starting from lack of exec_type on
> the bin_type, not following naming conventions, etc..
bin_type: Ooops.
What naming conventions did I miss?

Thanks for the policy, it is definitely much cleaner with macros
(although fundamentally not that different - which is good news for me),
Just few questions, does it really need:
* read access to all of etc_t and etc_runtime_t?
* self:capability dac_override ipc_lock
* read_sysctl(mdadm_t)
* r_dir_file(mdadm_t, sysfs_t)
* read_locale(mdadm_t)
Anyone know? Mine works without them.

I guess it allows execution of /bin and /sbin for the "PROGRAM" user
defined action, so I could keep it more restricted by only allowing
execution of sendmail_exec_t for my use. Since this is the only
statement in the policy that allows execution of external code, it feels
like the most important place to put restrictions on.

Thanks
Antoine


--
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: mdadm policy

[Stephen Smalley]

On Fri, 2005-06-24 at 00:27 +0100, antoine wrote:
> I was looking for a policy for mdadm, I know there is one in Fedora, but
> I use gentoo and I couldn't download it without getting the whole rpm,
> so I ended up writing one (attached) - it is also a good learning
> exercise. Shouldn't it be in serefpolicy.sourceforge.net?

The reference policy being developed by Tresys Technology is still in
early development, and doesn't yet include an equivalent to everything
from the upstream example policy.  But you can grab individual files
from the upstream example policy from the selinux sourceforge CVS tree,
e.g.:
http://cvs.sourceforge.net/viewcvs.py/selinux/nsa/selinux-usr/policy/domains/program/unused/mdadm.te?rev=1.14&view=log
http://cvs.sourceforge.net/viewcvs.py/selinux/nsa/selinux-usr/policy/file_contexts/program/mdadm.fc?rev=1.3&view=log

Also, there is a public Fedora CVS tree (but that likely doesn't help
too much, as you would still need to extract the files from the tarball,
since the Fedora CVS tree is organized for packaging rather than
upstream development, i.e. an upstream tarball + patches + spec file).

-- 
Stephen Smalley
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: mdadm policy

[Ivan Gyurdiev]

> What naming conventions did I miss?

The bin type should be named mdadm_exec_t, not mdadm_bin_t

> Thanks for the policy, it is definitely much cleaner with macros
> (although fundamentally not that different - which is good news for me),

It's Colin Walters' policy according to the header.

> Just few questions, does it really need:
> * read access to all of etc_t and etc_runtime_t?

The current policy assumes that etc_t and etc_runtime_t
are not protected types. It takes the opposite approach of 
marking specific types that should be protected. I find
this rather undesirable, but that's the way it is done...

Those rules are usually added to access /etc/fstab and
/etc/mtab.

> * self:capability dac_override ipc_lock

This looks interesting...

> * read_sysctl(mdadm_t)
> * r_dir_file(mdadm_t, sysfs_t)
> * read_locale(mdadm_t)
> Anyone know? Mine works without them.

Not sure, but those don't seem too much of a threat.
How do you know it works without them? Your setup
is just one of many... 

> I guess it allows execution of /bin and /sbin for the "PROGRAM" user
> defined action, so I could keep it more restricted by only allowing
> execution of sendmail_exec_t for my use.

Perhaps...

Note that the execution occurs without a transition (execute_no_trans),
which means that while executing the sub-program, it runs in
the same confined domain.

>  Since this is the only
> statement in the policy that allows execution of external code, it feels
> like the most important place to put restrictions on.

See above - execution of external code isn't so much of a problem
as long as it occurs in the same domain. If the external code
does anything undesirable, it will be done in the mdadm domain.



--
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: mdadm policy

[Colin Walters]

On Fri, 2005-06-24 at 11:41 -0400, Ivan Gyurdiev wrote:

> Those rules are usually added to access /etc/fstab and
> /etc/mtab.

And all the other random libc files.

> > * self:capability dac_override ipc_lock
> This looks interesting...

Could potentially be a problem; it'd be useful to track down what part
of the code needed it.

> > * read_sysctl(mdadm_t)
> > * r_dir_file(mdadm_t, sysfs_t)

I'm not sure why your version wouldn't need this.

> > * read_locale(mdadm_t)

You probably don't need this because you're using the "C" locale, but
the Fedora default is UTF-8, so it needs access to the locale files.



--
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: mdadm policy

[antoine]

> > I guess it allows execution of /bin and /sbin for the "PROGRAM" user
> > defined action, so I could keep it more restricted by only allowing
> > execution of sendmail_exec_t for my use.
> 
> Perhaps...
> 
> Note that the execution occurs without a transition (execute_no_trans),
> which means that while executing the sub-program, it runs in
> the same confined domain.
Well that's no comfort at all, mdadm_t domain has the ability to access
raw disks and send mail... That's worrying enough.

# RAID block device access
allow mdadm_t fixed_disk_device_t:blk_file create_file_perms;

> >  Since this is the only
> > statement in the policy that allows execution of external code, it feels
> > like the most important place to put restrictions on.
> 
> See above - execution of external code isn't so much of a problem
> as long as it occurs in the same domain. If the external code
> does anything undesirable, it will be done in the mdadm domain.
True as long as the domain is sufficiently constrained, which is not the
case for mdadm. I will tweak my policy to make it run sendmail in
sendmail_t and nothing else. That's safer than mdadm_t.

Antoine


--
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: mdadm policy

[Ivan Gyurdiev]

> Well that's no comfort at all, mdadm_t domain has the ability to access
> raw disks and send mail... That's worrying enough.

I don't see anything about sending mail, but perhaps
I'm not looking hard enough. You're talking about adding this
privilege?

> # RAID block device access
> allow mdadm_t fixed_disk_device_t:blk_file create_file_perms;

hmm..yes..

Well, in this case, mdadm_t is the trusted domain,
and you *want* to transition it to other domains upon execution
of something that you don't trust.

So yes, if  you want want to send mail, you would add 
a transition like this:
domain_auto_trans(mdadm_t, sendmail_exec_t, sendmail_t (or whatever..))

What is this PROGRAM configurable option - can you describe in more 
detail. I don't know anything about mdadm.

> I will tweak my policy to make it run sendmail in
> sendmail_t and nothing else. That's safer than mdadm_t.

Perhaps this is something that should be in default policy - it
sounds like a good threat model.


--
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: mdadm policy

[antoine]

On Fri, 2005-06-24 at 13:46 -0400, Ivan Gyurdiev wrote:
> > Well that's no comfort at all, mdadm_t domain has the ability to access
> > raw disks and send mail... That's worrying enough.
> 
> I don't see anything about sending mail, but perhaps
> I'm not looking hard enough. You're talking about adding this
> privilege?
Sorry, sending mail is not actually a function of mdadm (in code), it is
just a configuration option that pipes to sendmail:

>From the man page:

MAILADDR
The mailaddr line gives an E-mail address that alerts should be sent to
when is running in --monitor mode (and was given the --scan option).
There  should  only be one MAILADDR line and it should have only one
address.

PROGRAM
The  program  line  gives the name of a program to be run when mdadm
--monitor detects potentially interesting events on any of the arrays
that it is monitoring.
This program gets run with two or three arguments, they being the Event,
the md device, and possibly the related component device.
There should only be one program line and it should be give only one
program.


So it looks to me like the transition to sendmail should always be
included - well actually, ifdef(mta.te).

> > # RAID block device access
> > allow mdadm_t fixed_disk_device_t:blk_file create_file_perms;
> 
> hmm..yes..
> 
> Well, in this case, mdadm_t is the trusted domain,
> and you *want* to transition it to other domains upon execution
> of something that you don't trust.
> 
> So yes, if  you want want to send mail, you would add 
> a transition like this:
> domain_auto_trans(mdadm_t, sendmail_exec_t, sendmail_t (or whatever..))
> 
> What is this PROGRAM configurable option - can you describe in more 
> detail. I don't know anything about mdadm.
> 
> > I will tweak my policy to make it run sendmail in
> > sendmail_t and nothing else. That's safer than mdadm_t.
> 
> Perhaps this is something that should be in default policy - it
> sounds like a good threat model.

What should be the domain to transition to upon execution of bin/sbin?
Rather than using can_exec, I believe it should be:
domain_auto_trans(mdadm_t, bin_t, that_domain_t)
domain_auto_trans(mdadm_t, sbin_t, that_domain_t)
But personally, I'll leave that out and rely on the email notification.

Antoine


--
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: mdadm policy

[Ivan Gyurdiev]

> So it looks to me like the transition to sendmail should always be
> included - well actually, ifdef(mta.te).

cc-ed Dan Walsh.
Proposed transition to sendmail from mdadm.te
(so it can send alerts to user).

Re: can_exec({ bin_t, sbin_t }) rule

Antoine, you have to be root/sysadm_t to configure
execution of such programs, right? If you have sysadm_t, you
can disable any and all security. The only protection
from sysadm_t that selinux provides is protection from
inadvertently running hostile code that messes w/ selinux
files - that's why we have a role called secadm_t
(I think this is work in progress).

So, we can't stop an intentional attack like this.
The only question is whether we should stop unintentional
attack (sysadm doesn't know bin_t/sbin_t program is hostile,
sysadm installed it anyway, sysadm doesn't have capability
to write to fixed_disk_device, but mdadm does, and 
gives hostile program desired escalation). 

Don't know..

> > > # RAID block device access
> > > allow mdadm_t fixed_disk_device_t:blk_file create_file_perms;
> > 
> > hmm..yes..
> > 
> > Well, in this case, mdadm_t is the trusted domain,
> > and you *want* to transition it to other domains upon execution
> > of something that you don't trust.
> > 
> > So yes, if  you want want to send mail, you would add 
> > a transition like this:
> > domain_auto_trans(mdadm_t, sendmail_exec_t, sendmail_t (or whatever..))
> > 
> > What is this PROGRAM configurable option - can you describe in more 
> > detail. I don't know anything about mdadm.
> > 
> > > I will tweak my policy to make it run sendmail in
> > > sendmail_t and nothing else. That's safer than mdadm_t.
> > 
> > Perhaps this is something that should be in default policy - it
> > sounds like a good threat model.
> 
> What should be the domain to transition to upon execution of bin/sbin?
> Rather than using can_exec, I believe it should be:
> domain_auto_trans(mdadm_t, bin_t, that_domain_t)
> domain_auto_trans(mdadm_t, sbin_t, that_domain_t)
> But personally, I'll leave that out and rely on the email notification.
> 
> Antoine
> 
> 
> --
> 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.


--
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: mdadm policy

[antoine]

On Fri, 2005-06-24 at 15:05 -0400, Ivan Gyurdiev wrote:
> > So it looks to me like the transition to sendmail should always be
> > included - well actually, ifdef(mta.te).
> 
> cc-ed Dan Walsh.
> Proposed transition to sendmail from mdadm.te
> (so it can send alerts to user).
> 
> Re: can_exec({ bin_t, sbin_t }) rule
> 
> Antoine, you have to be root/sysadm_t to configure
> execution of such programs, right? If you have sysadm_t, you
> can disable any and all security. The only protection
> from sysadm_t that selinux provides is protection from
> inadvertently running hostile code that messes w/ selinux
> files - that's why we have a role called secadm_t
> (I think this is work in progress).
I admit the threat is minimal, but I just don't like the idea of running
things as mdadm_t when it isn't necessary.
You would need to know what is run by mdadm (as mdadm.conf is not
readable by non root/sysadm_t) *and* find a flaw in it *and* trigger the
mdadm error condition. Very slim indeed.
On the other hand, any flaw in one of the bin_t/sbin_t programs run by
mdadm would lead to a full compromise (using raw disks). And there has
been more than one flaw found in sendmail/postfix/... And since it is
avoidable, why not remove access to raw disks before launching the
program. (I think the transition to sendmail_t is the minimum)

> So, we can't stop an intentional attack like this.
> The only question is whether we should stop unintentional
> attack (sysadm doesn't know bin_t/sbin_t program is hostile,
> sysadm installed it anyway, sysadm doesn't have capability
> to write to fixed_disk_device, but mdadm does, and 
> gives hostile program desired escalation). 
Hostile program  *or* shell script with insecure privileges/files, etc.

Antoine


--
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: mdadm policy

[Ivan Gyurdiev]

> Hostile program  *or* shell script with insecure privileges/files, etc.

No, improperly secured (but non-hostile) program is 
not an issue, because remember... you're still running 
in the mdadm_t domain. Your program can't write any files, 
because mdadm_t is not allowed to. It has to explicitly
try to subvert this by writing to raw disk (at which point
it's obviously a hostile program).

In fact, if you try to run anything complicated at all it
will likely fail, and not work at all, including sendmail.

The only threat to me appears to be a root kit, but 
at that point you've already subverted selinux to a large
degree, and I'm not sure it's worth protecting anymore.






--
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: mdadm policy

[Stephen Smalley]

On Fri, 2005-06-24 at 20:27 +0100, antoine wrote:
> I admit the threat is minimal, but I just don't like the idea of running
> things as mdadm_t when it isn't necessary.
> You would need to know what is run by mdadm (as mdadm.conf is not
> readable by non root/sysadm_t) *and* find a flaw in it *and* trigger the
> mdadm error condition. Very slim indeed.
> On the other hand, any flaw in one of the bin_t/sbin_t programs run by
> mdadm would lead to a full compromise (using raw disks). And there has
> been more than one flaw found in sendmail/postfix/... And since it is
> avoidable, why not remove access to raw disks before launching the
> program. (I think the transition to sendmail_t is the minimum)

Yes, SELinux, or more generally type enforcement, is intended to be used
in this manner (binding specific privileges to specific code), thereby
significantly reducing the assurance burden on userspace.  Locking down
what a privileged domain can execute is highly desirable.

-- 
Stephen Smalley
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: mdadm policy

[Stephen Smalley]

On Fri, 2005-06-24 at 15:05 -0400, Ivan Gyurdiev wrote:
> So, we can't stop an intentional attack like this.
> The only question is whether we should stop unintentional
> attack (sysadm doesn't know bin_t/sbin_t program is hostile,
> sysadm installed it anyway, sysadm doesn't have capability
> to write to fixed_disk_device, but mdadm does, and 
> gives hostile program desired escalation). 

It isn't just hostile programs you are concerned about, but flawed
programs, both in terms of robustness (containing damage from a simple
mistake) and in terms of exploitation of a flawed program.  Ensuring
that a privileged domain can only execute a small set of carefully
controlled code is necessary in order to have any confidence here - you
can then focus your assurance effort on that small set of code.

-- 
Stephen Smalley
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: mdadm policy

[Daniel J Walsh]

antoine wrote:

>On Fri, 2005-06-24 at 15:05 -0400, Ivan Gyurdiev wrote:
>  
>
>>>So it looks to me like the transition to sendmail should always be
>>>included - well actually, ifdef(mta.te).
>>>      
>>>
>>cc-ed Dan Walsh.
>>Proposed transition to sendmail from mdadm.te
>>(so it can send alerts to user).
>>
>>Re: can_exec({ bin_t, sbin_t }) rule
>>
>>Antoine, you have to be root/sysadm_t to configure
>>execution of such programs, right? If you have sysadm_t, you
>>can disable any and all security. The only protection
>>from sysadm_t that selinux provides is protection from
>>inadvertently running hostile code that messes w/ selinux
>>files - that's why we have a role called secadm_t
>>(I think this is work in progress).
>>    
>>
>I admit the threat is minimal, but I just don't like the idea of running
>things as mdadm_t when it isn't necessary.
>You would need to know what is run by mdadm (as mdadm.conf is not
>readable by non root/sysadm_t) *and* find a flaw in it *and* trigger the
>mdadm error condition. Very slim indeed.
>On the other hand, any flaw in one of the bin_t/sbin_t programs run by
>mdadm would lead to a full compromise (using raw disks). And there has
>been more than one flaw found in sendmail/postfix/... And since it is
>avoidable, why not remove access to raw disks before launching the
>program. (I think the transition to sendmail_t is the minimum)
>
>  
>
>>So, we can't stop an intentional attack like this.
>>The only question is whether we should stop unintentional
>>attack (sysadm doesn't know bin_t/sbin_t program is hostile,
>>sysadm installed it anyway, sysadm doesn't have capability
>>to write to fixed_disk_device, but mdadm does, and 
>>gives hostile program desired escalation). 
>>    
>>
>Hostile program  *or* shell script with insecure privileges/files, etc.
>
>Antoine
>
>  
>
Add privmail attribute and you will transition to system_mail_t when 
starting sendmai.

-- 




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