From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Stephen Smalley <sds@epoch.ncsc.mil>
Cc: SE-Linux <selinux@tycho.nsa.gov>
Subject: Re: lots of allow xxx_device_t device_t:filesystem { associate }
Date: Mon, 9 Aug 2004 20:35:21 +0100 [thread overview]
Message-ID: <20040809193521.GN3868@lkcl.net> (raw)
In-Reply-To: <1092077016.29199.166.camel@moss-spartans.epoch.ncsc.mil>
On Mon, Aug 09, 2004 at 02:43:36PM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-09 at 13:52, Luke Kenneth Casson Leighton wrote:
> > i'm getting an awful lot of the above due to udev creating
> > inodes in /dev which i decided to associate with device_t.
>
> allow device_type device_t:filesystem associate;
> should cover most cases.
>
> > now i have had to add about 15 or 20 lines so far each for pretty
> > much every xxx_device_t under the sun, and am concerned that i
> > am taking the wrong approach.
>
> Other than the associate permission, what else do you need to add?
okay, i'm attaching my horrible_hacks.te file...
# this is to deal with restorecon devices being associated with udev's
# mounting of /dev as a fscontext=device_t. help, help, gloop!
allow console_device_t device_t:filesystem { associate };
allow devtty_t device_t:filesystem { associate };
allow fixed_disk_device_t device_t:filesystem { associate };
allow memory_device_t device_t:filesystem { associate };
allow mouse_device_t device_t:filesystem { associate };
allow null_device_t device_t:filesystem { associate };
allow ptmx_t device_t:filesystem { associate };
allow random_device_t device_t:filesystem { associate };
allow sound_device_t device_t:filesystem { associate };
allow tty_device_t device_t:filesystem { associate };
allow urandom_device_t device_t:filesystem { associate };
allow zero_device_t device_t:filesystem { associate };
allow device_t device_t:filesystem { associate };
allow initctl_t device_t:filesystem { associate };
allow udev_tbl_t device_t:filesystem { associate };
allow event_device_t device_t:filesystem { associate };
# this is to allow /etc/init.d/udev to do its horrible hacks
# if it wasn't done in /etc/init.d or it wasn't device_t under which
# /dev was mounted (mount ... -o fscontext=....device_t) then this
# would be different or not there:
allow initrc_t device_t:dir { create setattr };
#EXE=/bin/mkdir NAME=pts : create
#EXE=/bin/touch NAME=/ : setattr
allow initrc_t device_t:lnk_file { create };
#EXE=/bin/ln NAME=fd : create
allow initrc_t device_t:blk_file { getattr };
#EXE=/bin/ls PATH=/dev/ram0 : getattr
allow initrc_t device_t:chr_file { getattr read write };
#EXE=/bin/bash NAME=tty : read write
#EXE=/bin/ls PATH=/dev/ptmx : getattr
# not sure about this one
allow initrc_t fixed_disk_device_t:blk_file { getattr };
#EXE=/bin/bash PATH=/dev/ram0 : getattr
allow init_t device_t:fifo_file { getattr read write };
#EXE=/sbin/init PATH=/dev/initctl : getattr
#EXE=/sbin/init NAME=initctl : read write
#
# plus the allow udev ones...
--
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.
prev parent reply other threads:[~2004-08-09 19:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-09 17:52 lots of allow xxx_device_t device_t:filesystem { associate } Luke Kenneth Casson Leighton
2004-08-09 18:43 ` Stephen Smalley
2004-08-09 18:59 ` Luke Kenneth Casson Leighton
2004-08-09 19:09 ` Luke Kenneth Casson Leighton
2004-08-09 19:02 ` Stephen Smalley
2004-08-09 19:02 ` Stephen Smalley
2004-08-09 19:43 ` Luke Kenneth Casson Leighton
2004-08-09 19:43 ` Luke Kenneth Casson Leighton
2004-08-10 6:45 ` Russell Coker
2004-08-10 6:45 ` Russell Coker
2004-08-10 12:45 ` Luke Kenneth Casson Leighton
2004-08-10 12:45 ` Luke Kenneth Casson Leighton
2004-08-09 19:35 ` Luke Kenneth Casson Leighton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040809193521.GN3868@lkcl.net \
--to=lkcl@lkcl.net \
--cc=sds@epoch.ncsc.mil \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.