FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 09-12-2008, 12:35 PM
Gabriele Pohl
 
Default Hello world and first question concerning Munin

Hi all,

my name is Gabriele Pohl. I live in Bonn, Germany
and use Fedora for a few years (starting with
Core 4 and upgraded to 9 some months ago)

I use Munin (http://munin.projects.linpro.no/)
to monitor my computers hardware and services.
After upgrading to Fedora 9 I decided to use SELinux
in mode *enforce* and run into lots of problems
concerning SELinux and Munin-Plugins, that need
high system privileges to access block devices a.s.o.

I would like to solve this issues in a good
manner and therefore subscribed to this list
to ask the experts, how to do it.

Now my first question:

Plugin smart_ is written in Python.
It calls "smartctl" from the smartmontools package
(http://smartmontools.sourceforge.net/) to read the
values of the SMART-Attributes from the harddisks.

To activate the plugin, one has to create a link
within the service directory.

Actually the link looks like this:
lrwxrwxrwx root root unconfined_ubject_r:munin_etc_t:s0 smart_sda
-> /usr/share/munin/plugins/smart_

The plugins file looks like this:
-rwxr-xr-x root root
system_ubject_r:munin_exec_t:s0 /usr/share/munin/plugins/smart_

Executable smartctl looks like this:
-rwxr-xr-x root root
system_ubject_r:fsadm_exec_t:s0 /usr/sbin/smartctl

It needs access to the disks block device /dev/sda
that looks like this:
brw-rw---- root disk system_ubject_r:fixed_disk_device_t:s0 /dev/sda

I have policy type targeted active and
policy module munin 1.4.0 installed.

I get the following raw audit messages, when
calling smart_sda:

host=calex.dipohl.com type=AVC msg=audit(1221221404.542:709): avc:
denied { getattr } for pid=18327 comm="python" path="/dev/sda" dev=tmpfs
ino=298 scontext=unconfined_u:system_r:munin_t:s0
tcontext=system_ubject_r:fixed_disk_device_t:s0 tclass=blk_file

host=calex.dipohl.com type=SYSCALL msg=audit(1221221404.542:709):
arch=40000003 syscall=195 success=no exit=-13 a0=8fbe278 a1=bfcdf038
a2=3e8ff4 a3=8f481b8 items=0 ppid=18220 pid=18327 auid=500 uid=0 gid=491
euid=0 suid=0 fsuid=0 egid=491 sgid=491 fsgid=491 tty=(none) ses=1
comm="python" exe="/usr/bin/python"
subj=unconfined_u:system_r:munin_t:s0 key=(null)

As the FAQ said, I fed these messages into audit2allow:
audit2allow -M mine < avcs

and get the following mine.te:
-------------------------------
module mine 1.0;

require {
type munin_t;
type fixed_disk_device_t;
class blk_file getattr;
}
require {
type munin_t;
type fixed_disk_device_t;
class blk_file getattr;
}

#============= munin_t ==============
allow munin_t fixed_disk_device_t:blk_file getattr;
-------------------------------

and a mine.pp

Will it be ok to load that into the kernel using
semodule -i mine.pp ?

And why are there two identical *require* structs?
Can / Should I delete one of them?
What shall I do with the message of type "SYSCALL"
if it were wrong to put it into the avcs-File?

Should I make adjustments to the files above
(service-link, plugin-file)

Anything else, that you can advise?

So far for now & cheers,

Gabriele

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 
Old 09-12-2008, 01:49 PM
Stephen Smalley
 
Default Hello world and first question concerning Munin

On Fri, 2008-09-12 at 14:35 +0200, Gabriele Pohl wrote:
> Hi all,
>
> my name is Gabriele Pohl. I live in Bonn, Germany
> and use Fedora for a few years (starting with
> Core 4 and upgraded to 9 some months ago)
>
> I use Munin (http://munin.projects.linpro.no/)
> to monitor my computers hardware and services.
> After upgrading to Fedora 9 I decided to use SELinux
> in mode *enforce* and run into lots of problems
> concerning SELinux and Munin-Plugins, that need
> high system privileges to access block devices a.s.o.
>
> I would like to solve this issues in a good
> manner and therefore subscribed to this list
> to ask the experts, how to do it.
>
> Now my first question:
>
> Plugin smart_ is written in Python.
> It calls "smartctl" from the smartmontools package
> (http://smartmontools.sourceforge.net/) to read the
> values of the SMART-Attributes from the harddisks.
>
> To activate the plugin, one has to create a link
> within the service directory.
>
> Actually the link looks like this:
> lrwxrwxrwx root root unconfined_ubject_r:munin_etc_t:s0 smart_sda
> -> /usr/share/munin/plugins/smart_
>
> The plugins file looks like this:
> -rwxr-xr-x root root
> system_ubject_r:munin_exec_t:s0 /usr/share/munin/plugins/smart_
>
> Executable smartctl looks like this:
> -rwxr-xr-x root root
> system_ubject_r:fsadm_exec_t:s0 /usr/sbin/smartctl
>
> It needs access to the disks block device /dev/sda
> that looks like this:
> brw-rw---- root disk system_ubject_r:fixed_disk_device_t:s0 /dev/sda
>
> I have policy type targeted active and
> policy module munin 1.4.0 installed.
>
> I get the following raw audit messages, when
> calling smart_sda:
>
> host=calex.dipohl.com type=AVC msg=audit(1221221404.542:709): avc:
> denied { getattr } for pid=18327 comm="python" path="/dev/sda" dev=tmpfs
> ino=298 scontext=unconfined_u:system_r:munin_t:s0
> tcontext=system_ubject_r:fixed_disk_device_t:s0 tclass=blk_file
>
> host=calex.dipohl.com type=SYSCALL msg=audit(1221221404.542:709):
> arch=40000003 syscall=195 success=no exit=-13 a0=8fbe278 a1=bfcdf038
> a2=3e8ff4 a3=8f481b8 items=0 ppid=18220 pid=18327 auid=500 uid=0 gid=491
> euid=0 suid=0 fsuid=0 egid=491 sgid=491 fsgid=491 tty=(none) ses=1
> comm="python" exe="/usr/bin/python"
> subj=unconfined_u:system_r:munin_t:s0 key=(null)
>
> As the FAQ said, I fed these messages into audit2allow:
> audit2allow -M mine < avcs
>
> and get the following mine.te:
> -------------------------------
> module mine 1.0;
>
> require {
> type munin_t;
> type fixed_disk_device_t;
> class blk_file getattr;
> }
> require {
> type munin_t;
> type fixed_disk_device_t;
> class blk_file getattr;
> }
>
> #============= munin_t ==============
> allow munin_t fixed_disk_device_t:blk_file getattr;
> -------------------------------
>
> and a mine.pp
>
> Will it be ok to load that into the kernel using
> semodule -i mine.pp ?
>
> And why are there two identical *require* structs?
> Can / Should I delete one of them?
> What shall I do with the message of type "SYSCALL"
> if it were wrong to put it into the avcs-File?
>
> Should I make adjustments to the files above
> (service-link, plugin-file)
>
> Anything else, that you can advise?

Ideally the munin_t domain itself shouldn't need any access to the raw
device - it should transition into the existing domain for smartd
(fsdaemon_t) upon executing the smartctl program. I don't know offhand
if the existing munin policy module has such a domain transition rule.

However, mere getattr access (i.e. the ability to stat the file) isn't a
big deal, so you could likely grant that one w/o difficulty. What would
be more problematic is allowing read or write access to the raw device.

The duplicate require blocks look like a bug in audit2allow.

--
Stephen Smalley
National Security Agency

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
 

Thread Tools




All times are GMT. The time now is 04:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org