12:37 p.m.
Just an idea, but why not have udev set the context on its root path?
I have a simplistic patch for this if its a good idea.
Regards
Nigel Kukard
3:31 p.m.
On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote:
Just an idea, but why not have udev set the context on its root path?
you mean on /dev, i presume?
well i had to patch selinux/hooks.c to allow this [on a tmpfs]
by relaxing the criteria of the "fscontext=" option for mount.
otherwise it's not _possible_ t set the context on /dev as it is
mounted [on a tmpfs].
[if /dev was a persistent filesystem everything would be hunky-dory
and this wouldn't be an issue].
with that in mind, it's more that because you're putting device
inodes into a non-persistent filesystem, you end up getting the
"default" rules and so you must "restore" the contexts, or
you must patch udev to "understand" the contents of
/etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
and setfscreatecon() from libselinux) such that it will create
inodes with the right file context.
like i said, if /dev was a persistent filesystem, and if device
inodes never disappeared, this wouldn't be a problem: you could run
setfiles /etc/selinux/src/file_contexts/file_contexts /dev and
be done with it...
... but that's not how udev works: it deletes and creates inodes
on demand; nothing exists at boot-time, it's all created on-demand.
so, not only must udev be patched to restore contexts but also
the policies and various hacks added to "cope" with /dev being
incredibly basic at startup - prior to udev running.
_including_ dealing with getting the contexts correct on entries
in /.dev [the old /dev remounted with mount --rbind]
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl(a)lkcl.net </a> <br />
12:02 a.m.
you mean on /dev, i presume?
yep, or /udev (configured in the udev config file)
well i had to patch selinux/hooks.c to allow this [on a tmpfs]
by relaxing the criteria of the "fscontext=" option for mount.
if its tmpfs, this would void the requirement of passing a mount option
fscontext, udev would set the correct context when started up (a check
could also be added to do this only if the mount point is /dev and its
tmpfs... *shrug*)
otherwise it's not _possible_ t set the context on /dev as it
is
mounted [on a tmpfs].
[if /dev was a persistent filesystem everything would be hunky-dory
and this wouldn't be an issue].
*nod*
with that in mind, it's more that because you're putting device
inodes into a non-persistent filesystem, you end up getting the
"default" rules and so you must "restore" the contexts, or
you must patch udev to "understand" the contents of
/etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
and setfscreatecon() from libselinux) such that it will create
inodes with the right file context.
I applied the patch to tmpfs to make it store xattr attributes which i
found on the mailing list, seems your patch forgets xattr.h?
I also applied the patch which adds "matchpathcon()" &
"setfscreatecon()" support, and modified udev to set the correct
context of its root_path on startup.
... but that's not how udev works: it deletes and creates
inodes
on demand; nothing exists at boot-time, it's all created on-demand.
at boot time i have about 5 devices in /dev with correct contexts set,
udev them mounts tmpfs over this, WorksForMe(tm)
so in actual fact we do need matchpathcon() & setfscreatecon(), if its a
persistent or non-persistent filesystem
so, not only must udev be patched to restore contexts but also
the policies and various hacks added to "cope" with /dev being
incredibly basic at startup - prior to udev running.
i have a simple persistent /dev which is used before udev runs, udev is
then initialized, mounts a tmpfs over /dev (and restores its context) just
after sysctl -p is run in my initscripts so its basically one of the
first things to run. Seeing as my initial /dev is on a persistent
filesystem i don't have a problem with pre-udev stuff running.
_including_ dealing with getting the contexts correct on entries
in /.dev [the old /dev remounted with mount --rbind]
l.
--
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web: www.lbsd.net Email: nkukard(a)lbsd.net
Tel: (+27) 023 349 8000 Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395 Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions
The best language to use is the language that was designed for
what you want to use it for.
=====================================================================
Disclaimer
----------
The contents of this message and any attachments are intended
solely for the addressee's use and may be legally privileged and/or
confidential information. This message may not be retained,
distributed, copied or used if you are not he addressee of this
message. If this message was sent to you in error, please notify
the sender immediately by reply e-mail and then destroy the message
and any copies thereof.
Opinions, conclusions and other information in this message may be
personal to the sender and is not that of Linux Based Systems Design,
LinuxRulz or any of it's subsideries, associated companies or
principals and is therefore not endorsed by Linux Based Systems
Design or LinuxRulz. Due to e-maill communication being insecure,
Linux Based Systems Design and LinuxRulz do not guarantee
confidentiality, security, accuracy or performance of the e-mail.
Any liability for viruses is excluded to the fullest extent.
4:49 a.m.
On Tue, Aug 31, 2004 at 07:02:52AM +0200, Nigel Kukard wrote:
> you mean on /dev, i presume?
yep, or /udev (configured in the udev config file)
oh.
yes.
redhat :)
>
> well i had to patch selinux/hooks.c to allow this [on a tmpfs]
> by relaxing the criteria of the "fscontext=" option for mount.
>
if its tmpfs, this would void the requirement of passing a mount option
fscontext, udev would set the correct context when started up (a check
could also be added to do this only if the mount point is /dev and its
tmpfs... *shrug*)
> otherwise it's not _possible_ t set the context on /dev as it is
> mounted [on a tmpfs].
>
> [if /dev was a persistent filesystem everything would be hunky-dory
> and this wouldn't be an issue].
>
*nod*
>
> with that in mind, it's more that because you're putting device
> inodes into a non-persistent filesystem, you end up getting the
> "default" rules and so you must "restore" the contexts, or
> you must patch udev to "understand" the contents of
> /etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
> and setfscreatecon() from libselinux) such that it will create
> inodes with the right file context.
>
I applied the patch to tmpfs to make it store xattr attributes which i
found on the mailing list, seems your patch forgets xattr.h?
?? oops.
okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/
and when i posted copies to the list i must have missed it out.
if you _do_ know how to properly create patches that other people
can apply simply, that'd be great.
I also applied the patch which adds "matchpathcon()" &
"setfscreatecon()" support,
dan is working on a new version of that, for udev-0.030-10.
and modified udev to set the correct
context of its root_path on startup.
mount -o fscontext=system_u:object_r:device_t yes?
did you patch selinux/hooks.c to relax the constraints on
the fscontext= parameter to allow the correct context to be
correctly applied? :)
> ... but that's not how udev works: it deletes and creates
inodes
> on demand; nothing exists at boot-time, it's all created on-demand.
at boot time i have about 5 devices in /dev with correct contexts set,
udev them mounts tmpfs over this, WorksForMe(tm)
so in actual fact we do need matchpathcon() & setfscreatecon(), if its a
persistent or non-persistent filesystem
yep.
>
> so, not only must udev be patched to restore contexts but also
> the policies and various hacks added to "cope" with /dev being
> incredibly basic at startup - prior to udev running.
i have a simple persistent /dev which is used before udev runs, udev is
then initialized, mounts a tmpfs over /dev (and restores its context)
oh. ah.... you _restore_ its context (i.e. run restorecon
/dev), you don't mount it with the modified mount -o fscontext=
parameter?
just
after sysctl -p is run in my initscripts so its basically one of the
first things to run.
yep.
Seeing as my initial /dev is on a persistent
filesystem i don't have a problem with pre-udev stuff running.
well.... you shouldn't... until you reinitialise or somehow delete,
upgrade or otherwise modify the "old" /dev [which you will find is
remounted --rbind to /.dev].
try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev
and then reboot [in permissive mode!!!]
due to the present files/types.fc, you will find that the entire
/.dev gets relabelled to something completely useless: root_t
or default_t. i think it's default_t.
consequently your next reboot in enforcing mode will fail because
/sbin/init tries to access /dev/null and /dev/initctl etc. as
default_t ... and it can't.
should you choose to deal with this, replace /u?dev with /[\.u]dev or
some suitable regexp that i haven't a clue how to write so i just
did /.?u?dev and that did the trick.
the only _other_ thing you might find is that things like dialup
don't or won't have been loaded.
so i had to add in a _second_ version of /etc/init.d/modutils which
does exactly the same as /etc/init.d/modutils ... but with a different
list of modules, and AFTER udev has been run, not before.
the list i have so far in /etc/modules.postudev contains (for my purposes):
ppp_generic
nvidia
sg
ppp_generic is there because "pon provider" bitches about /dev/ppp
not existing
sg is there because of usb-mount using sg_mod: if the module is
pre-loaded, then /dev/sg0 gets created by udev.
i don't believe that these modules should be loaded prior to udev
being run: maybe they can, maybe they can't, maybe the nodes being
loaded prior will result in a pending hotplug event such that when
udev is run, the node gets created.
... but certainly, _some_ modules haven't been modified to conform
to the new /sys thing.
the "trick" of a node in /dev existing, and its first access
automatically triggering a modprobe... well that only works if
the node is there, and of course with udev, it isn't.
perhaps there should be a "hook" into tmpfs to be able to pass
filenames accessed in /dev on to udev, such that udev can go
"oo, they tried to access /dev/ppp, let's kick off that module,
then".
l.
5:27 a.m.
On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote:
> yep, or /udev (configured in the udev config file)
oh.
yes.
redhat :)
no... it just depends how you want it configured ;-)
> I applied the patch to tmpfs to make it store xattr attributes
which i
> found on the mailing list, seems your patch forgets xattr.h?
?? oops.
okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/
and when i posted copies to the list i must have missed it out.
if you _do_ know how to properly create patches that other people
can apply simply, that'd be great.
*nod*, i'm pondering creating the patches... let me see what i can do
> I also applied the patch which adds "matchpathcon()"
&
> "setfscreatecon()" support,
dan is working on a new version of that, for udev-0.030-10.
cool, that will at least remove 1 patch out my build tree
> and modified udev to set the correct
> context of its root_path on startup.
mount -o fscontext=system_u:object_r:device_t yes?
nope.... mount -t ramfs none /dev
then run udevstart (udevstart does the C call to restorecon on
root_path, so it ends up being labeled with whatever is configured)
did you patch selinux/hooks.c to relax the constraints on
the fscontext= parameter to allow the correct context to be
correctly applied? :)
correct, not sure if this is the 100% right way to do it though, I think
it would be better for the capabilities of the fs to be set properly
instead of commenting out code, this will have better chance being
included mainstream.
> >
> > so, not only must udev be patched to restore contexts but also
> > the policies and various hacks added to "cope" with /dev being
> > incredibly basic at startup - prior to udev running.
>
> i have a simple persistent /dev which is used before udev runs, udev is
> then initialized, mounts a tmpfs over /dev (and restores its context)
oh. ah.... you _restore_ its context (i.e. run restorecon
/dev), you don't mount it with the modified mount -o fscontext=
parameter?
correct!, it does the restore in udevstart
> Seeing as my initial /dev is on a persistent
> filesystem i don't have a problem with pre-udev stuff running.
well.... you shouldn't... until you reinitialise or somehow delete,
upgrade or otherwise modify the "old" /dev [which you will find is
remounted --rbind to /.dev].
got no reason to add other entries to the pre-udev /dev, so as I said
ItWorksForMe(tm).
try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev
and then reboot [in permissive mode!!!]
due to the present files/types.fc, you will find that the entire
/.dev gets relabelled to something completely useless: root_t
or default_t. i think it's default_t.
yep, i'm 100% aware of this... i don't need /.dev, nor do I have it, nor
do I want it ... heh, on installation of our distribution the pre-udev
/dev is created and labeled correctly.
consequently your next reboot in enforcing mode will fail because
/sbin/init tries to access /dev/null and /dev/initctl etc. as
default_t ... and it can't.
yep, but as I said... i don't label pre-udev /dev when udev is running,
before I added it to our distro installer I mounted /dev/hda1 (root) as
/mnt/hda1, chroot'd onto it and re-labeled the files there (basically
the same thing our installer does)
should you choose to deal with this, replace /u?dev with /[\.u]dev
or
some suitable regexp that i haven't a clue how to write so i just
did /.?u?dev and that did the trick.
thats a good idea ;-), although in "my" case didn't need it.
the only _other_ thing you might find is that things like dialup
don't or won't have been loaded.
i don't have any problems with this ;-)
so i had to add in a _second_ version of /etc/init.d/modutils which
does exactly the same as /etc/init.d/modutils ... but with a different
list of modules, and AFTER udev has been run, not before.
the list i have so far in /etc/modules.postudev contains (for my purposes):
ppp_generic
nvidia
sg
no probs with any of these either (and yes we do use them), the pc i'm
on runs dual-head nvidia ;-)
every distro is different, so i would expect some to gulp bubbles and
some not to... *shrug*
i don't believe that these modules should be loaded prior to
udev
being run: maybe they can, maybe they can't, maybe the nodes being
loaded prior will result in a pending hotplug event such that when
udev is run, the node gets created.
we load them after udev, and everything ends up labeled correctly...
for instance...
ot(a)localhost.localdomain policy]# ls -Z /dev/ppp
ls: /dev/ppp: No such file or directory
[root(a)localhost.localdomain policy]# modprobe ppp_generic
[root(a)localhost.localdomain policy]# ls -Z /dev/ppp
crw------- root root system_u:object_r:ppp_device_t /dev/ppp
[root(a)localhost.localdomain policy]#
perhaps there should be a "hook" into tmpfs to be able to
pass
filenames accessed in /dev on to udev, such that udev can go
"oo, they tried to access /dev/ppp, let's kick off that module,
then".
if you need any of my initscripts or anything, give me a shout, i've
nearly got a 100% functional selinux enabled server! ;-)
just writing a few security policies
--
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web: www.lbsd.net Email: nkukard(a)lbsd.net
Tel: (+27) 023 349 8000 Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395 Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions
The best language to use is the language that was designed for
what you want to use it for.
=====================================================================
Disclaimer
----------
The contents of this message and any attachments are intended
solely for the addressee's use and may be legally privileged and/or
confidential information. This message may not be retained,
distributed, copied or used if you are not he addressee of this
message. If this message was sent to you in error, please notify
the sender immediately by reply e-mail and then destroy the message
and any copies thereof.
Opinions, conclusions and other information in this message may be
personal to the sender and is not that of Linux Based Systems Design,
LinuxRulz or any of it's subsideries, associated companies or
principals and is therefore not endorsed by Linux Based Systems
Design or LinuxRulz. Due to e-maill communication being insecure,
Linux Based Systems Design and LinuxRulz do not guarantee
confidentiality, security, accuracy or performance of the e-mail.
Any liability for viruses is excluded to the fullest extent.
7:46 a.m.
On Tue, Aug 31, 2004 at 12:27:15PM +0200, Nigel Kukard wrote:
> > and modified udev to set the correct
> > context of its root_path on startup.
>
> mount -o fscontext=system_u:object_r:device_t yes?
>
nope.... mount -t ramfs none /dev
then run udevstart (udevstart does the C call to restorecon on
root_path, so it ends up being labeled with whatever is configured)
oh, does it?
oh!
> did you patch selinux/hooks.c to relax the constraints on
> the fscontext= parameter to allow the correct context to be
> correctly applied? :)
>
correct, not sure if this is the 100% right way to do it though, I think
it would be better for the capabilities of the fs to be set properly
instead of commenting out code, this will have better chance being
included mainstream.
well if someone wants to write a new patch to hooks.c and invent
a new mount -o option oh i dunno overridecontext=.... then sure.
it's all the same to me.
> > >
> > > so, not only must udev be patched to restore contexts but also
> > > the policies and various hacks added to "cope" with /dev being
> > > incredibly basic at startup - prior to udev running.
> >
> > i have a simple persistent /dev which is used before udev runs, udev is
> > then initialized, mounts a tmpfs over /dev (and restores its context)
>
> oh. ah.... you _restore_ its context (i.e. run restorecon
> /dev), you don't mount it with the modified mount -o fscontext=
> parameter?
correct!, it does the restore in udevstart
ok.
my question is: is this desirable behaviour?
> > Seeing as my initial /dev is on a persistent
> > filesystem i don't have a problem with pre-udev stuff running.
>
> well.... you shouldn't... until you reinitialise or somehow delete,
> upgrade or otherwise modify the "old" /dev [which you will find is
> remounted --rbind to /.dev].
got no reason to add other entries to the pre-udev /dev, so as I said
ItWorksForMe(tm).
>
> try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev
> and then reboot [in permissive mode!!!]
>
> due to the present files/types.fc, you will find that the entire
> /.dev gets relabelled to something completely useless: root_t
> or default_t. i think it's default_t.
yep, i'm 100% aware of this... i don't need /.dev, nor do I have it, nor
do I want it ... heh, on installation of our distribution the pre-udev
/dev is created and labeled correctly.
... how?
and can you guarantee that it will _stay_ labelled correctly?
>
> consequently your next reboot in enforcing mode will fail because
> /sbin/init tries to access /dev/null and /dev/initctl etc. as
> default_t ... and it can't.
>
yep, but as I said... i don't label pre-udev /dev when udev is running,
before I added it to our distro installer I mounted /dev/hda1 (root) as
/mnt/hda1, chroot'd onto it and re-labeled the files there (basically
the same thing our installer does)
that's cheating :)
> the list i have so far in /etc/modules.postudev contains (for
my purposes):
>
> ppp_generic
> nvidia
> sg
>
no probs with any of these either (and yes we do use them), the pc i'm
on runs dual-head nvidia ;-)
bizarre.
how do you deal with that?
perhaps an answer would be best off-selinux list because it's not
entirely relevant to selinux, more the use of it.
every distro is different, so i would expect some to gulp bubbles
and
some not to... *shrug*
> i don't believe that these modules should be loaded prior to udev
> being run: maybe they can, maybe they can't, maybe the nodes being
> loaded prior will result in a pending hotplug event such that when
> udev is run, the node gets created.
we load them after udev, and everything ends up labeled correctly...
for instance...
ot(a)localhost.localdomain policy]# ls -Z /dev/ppp
ls: /dev/ppp: No such file or directory
[root(a)localhost.localdomain policy]# modprobe ppp_generic
^^^^^^^^^^^^^^^^^^^^
this is the bit that my /etc/init.d/modutils.postudev initscript
does for me: i'd be interested to know if you do something similar.
i can't be telling users to do _that_ they're unlikely
even know what a ppp is, that a modprobe is something to do
with police investigations in the 70s into the sex pistols,
and if you mentioned xterm they'd call rentakill.
[root(a)localhost.localdomain policy]# ls -Z /dev/ppp
crw------- root root system_u:object_r:ppp_device_t /dev/ppp
[root(a)localhost.localdomain policy]#
yes, this i'd expect to happen... _if_ the modprobe ppp_generic command
is ever issued [and users shouldn't be expected to do it!]
> perhaps there should be a "hook" into tmpfs to be
able to pass
> filenames accessed in /dev on to udev, such that udev can go
> "oo, they tried to access /dev/ppp, let's kick off that module,
> then".
if you need any of my initscripts or anything, give me a shout, i've
nearly got a 100% functional selinux enabled server! ;-)
if you could place them on a convenient http-accessible server
somewhere near you, that'd be great.
l.
6:26 a.m.
On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote:
> Seeing as my initial /dev is on a persistent
> filesystem i don't have a problem with pre-udev stuff running.
well.... you shouldn't... until you reinitialise or somehow delete,
upgrade or otherwise modify the "old" /dev [which you will find is
remounted --rbind to /.dev].
try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev
and then reboot [in permissive mode!!!]
due to the present files/types.fc, you will find that the entire
/.dev gets relabelled to something completely useless: root_t
or default_t. i think it's default_t.
consequently your next reboot in enforcing mode will fail because
/sbin/init tries to access /dev/null and /dev/initctl etc. as
default_t ... and it can't.
should you choose to deal with this, replace /u?dev with /[\.u]dev or
some suitable regexp that i haven't a clue how to write so i just
did /.?u?dev and that did the trick.
it's insufficient to add /.?u?dev to just file_contexts/types.fc
you also have to search in file_contexts/program/* for /dev
and set the right context there, too.
there is i believe a bug at present in
e.g. file_contexts/program/init.fc because it only covers
/dev/initctl not /udev/initctl and not /.dev/initctl.
i think this one is the only one that's really really critical
[except on redhat of course where they all should be /u?dev]
because if /.dev/initctl gets set to default_t, you're stuffed
at next boot.
l.
11:07 a.m.
On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote:
Just an idea, but why not have udev set the context on its root
path?
I have a simplistic patch for this if its a good idea.
ah ha. very funny.
now i have re-read what you've said, now that i have enough
background based on your further explanations in this thread,
_now_ i have enough context to understand your question.
okay.
let me reiterate what i believe you have said.
you have patched the program udev (0.030-10?)
[and yes, i would highly recommend sending it to the list(s)
to make it clear what you mean].
this patch will run, when it starts up, a call to setfilecon()
on /dev (or /udev, or whatever the mount point of the devfs is).
and _just_ on "/dev".
yes?
and it's done BEFORE any inodes are EVER created in the new
/dev, yes?
assuming yes, then it kinda-solves the need for doing that hacked-up
relaxed-constraints-patch-to-hooks.c fscontext= option.
why? because you can mount -t tmpfs /dev blah blah and you don't
care what the context is because udev will set the correct one
when it runs.
that is - of course - assuming that file_contexts/file_contexts
_contains_ the correct file context for /dev.
it might make (i dunno) for a simpler policy.
what i mean is, have you had to add in the modifications to the
selinux policy that i sent to the lists last week?
e.g. these:
allow udev_tbl_t device_t:filesystem { associate };
allow initctl_t device_t:filesystem { associate };
and these:
+# needed for udev-mounted (/dev) tmpfs
+allow $1_tty_device_t device_t:filesystem { associate };
+
+# to allow users to run df on udev-mounted (/dev) tmpfs
+allow $1_t device_t:filesystem { getattr };
+ #EXE=/bin/df NAME=/ : getattr
+
these are all there for reasons i cannot entirely fathom but
it starts, in types/file.te, with this:
allow { device_type } device_t:filesystem associate;
which is all because of this:
mount tmpfs -o fscontext=system_u:object_r:device_t /dev
anyway what i am saying is that if you HAVE NOT got all these patches
in your selinux policy files, then your approach has distinct
advantages: less mods to the policy files and less differences between
a persistent and non-persistent udev filesystem.
other than that, my intuition is saying "i don't like it" and what that
means is that in about two or three weeks i will be able to articulate
clearly and precisely why i don't think it's a good idea.
it'll likely be something to do with your solution being a two-step
operation whereas the hacked-up-relaxed-fscontext-hooks.c things is
a one-step (atomic?) operation.
l.
11:46 a.m.
you have patched the program udev (0.030-10?)
[and yes, i would highly recommend sending it to the list(s)
to make it clear what you mean].
this patch will run, when it starts up, a call to setfilecon()
on /dev (or /udev, or whatever the mount point of the devfs is).
and _just_ on "/dev".
yes?
correct
and it's done BEFORE any inodes are EVER created in the new
/dev, yes?
correct
assuming yes, then it kinda-solves the need for doing that hacked-up
relaxed-constraints-patch-to-hooks.c fscontext= option.
aha, u correct!!!!
why? because you can mount -t tmpfs /dev blah blah and you don't
care what the context is because udev will set the correct one
when it runs.
perfect!!!!, so that solves the need for the hooks patch, which is in
actual fact wrong.
that is - of course - assuming that file_contexts/file_contexts
_contains_ the correct file context for /dev.
*nod*
it might make (i dunno) for a simpler policy.
yep
what i mean is, have you had to add in the modifications to the
selinux policy that i sent to the lists last week?
e.g. these:
allow udev_tbl_t device_t:filesystem { associate };
allow initctl_t device_t:filesystem { associate };
and these:
+# needed for udev-mounted (/dev) tmpfs
+allow $1_tty_device_t device_t:filesystem { associate };
+
+# to allow users to run df on udev-mounted (/dev) tmpfs
+allow $1_t device_t:filesystem { getattr };
+ #EXE=/bin/df NAME=/ : getattr
+
had to add quite a couple more, but i'm still working on that to make it
"correct"
these are all there for reasons i cannot entirely fathom but
it starts, in types/file.te, with this:
allow { device_type } device_t:filesystem associate;
i need this aswell.... which is very interesting, so my "way of doing
it" doesn't solve this problem. i'll keep looking for the solution
which is all because of this:
mount tmpfs -o fscontext=system_u:object_r:device_t /dev
this doesn't cause the problem, its something else
anyway what i am saying is that if you HAVE NOT got all these patches
in your selinux policy files, then your approach has distinct
advantages: less mods to the policy files and less differences between
a persistent and non-persistent udev filesystem.
correct, i'm still working on it though and it HAS TO BE COMPLETED
SOON!!!!
other than that, my intuition is saying "i don't like it" and what that
means is that in about two or three weeks i will be able to articulate
clearly and precisely why i don't think it's a good idea.
*shrug*, just a different outlook, patching userspace instead of kernel
space
it'll likely be something to do with your solution being a
two-step
operation whereas the hacked-up-relaxed-fscontext-hooks.c things is
a one-step (atomic?) operation.
kernel developers will very much not like to get patches unless for a
very good reason... *shrug*... guess i have the totally oposite outlook
than you, i've had quite a number of my patches go mainstream though
l.
-Nigel
--
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web: www.lbsd.net Email: nkukard(a)lbsd.net
Tel: (+27) 023 349 8000 Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395 Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions
The best language to use is the language that was designed for
what you want to use it for.
2:18 p.m.
On Tue, Aug 31, 2004 at 06:46:35PM +0200, Nigel Kukard wrote:
> assuming yes, then it kinda-solves the need for doing that
hacked-up
> relaxed-constraints-patch-to-hooks.c fscontext= option.
>
aha, u correct!!!!
> why? because you can mount -t tmpfs /dev blah blah and you don't
> care what the context is because udev will set the correct one
> when it runs.
>
>
perfect!!!!, so that solves the need for the hooks patch, which is in
actual fact wrong.
oh, is it? uhm, why?
> that is - of course - assuming that
file_contexts/file_contexts
> _contains_ the correct file context for /dev.
>
>
*nod*
> it might make (i dunno) for a simpler policy.
>
yep
i _say_ might ... but then you mention that you've done exactly
the same policy mods that i had to...
> what i mean is, have you had to add in the modifications to
the
> selinux policy that i sent to the lists last week?
>
> e.g. these:
>
> allow udev_tbl_t device_t:filesystem { associate };
> allow initctl_t device_t:filesystem { associate };
>
> and these:
>
> +# needed for udev-mounted (/dev) tmpfs
> +allow $1_tty_device_t device_t:filesystem { associate };
> +
> +# to allow users to run df on udev-mounted (/dev) tmpfs
> +allow $1_t device_t:filesystem { getattr };
> + #EXE=/bin/df NAME=/ : getattr
> +
>
had to add quite a couple more, but i'm still working on that to make it
"correct"
i think we need the input of more experienced people than us to
say why these associate things are needed.
> these are all there for reasons i cannot entirely fathom but
> it starts, in types/file.te, with this:
>
> allow { device_type } device_t:filesystem associate;
>
i need this aswell.... which is very interesting, so my "way of doing
it" doesn't solve this problem. i'll keep looking for the solution
> which is all because of this:
>
> mount tmpfs -o fscontext=system_u:object_r:device_t /dev
>
this doesn't cause the problem, its something else
>
> anyway what i am saying is that if you HAVE NOT got all these patches
> in your selinux policy files, then your approach has distinct
> advantages: less mods to the policy files and less differences between
> a persistent and non-persistent udev filesystem.
>
correct, i'm still working on it though and it HAS TO BE COMPLETED
SOON!!!!
ah, the joys of the "ItWorksForMe(tm)" approach...
>
> other than that, my intuition is saying "i don't like it" and what
that
> means is that in about two or three weeks i will be able to articulate
> clearly and precisely why i don't think it's a good idea.
>
*shrug*, just a different outlook, patching userspace instead of kernel
space
> it'll likely be something to do with your solution being a
two-step
> operation whereas the hacked-up-relaxed-fscontext-hooks.c things is
> a one-step (atomic?) operation.
>
kernel developers will very much not like to get patches unless for a
very good reason...
a correct implementation of the
hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
operation (mount with a new context which would otherwise need to be
achieved with two commands: mount followed by restorecon)
in my books, that's a good reason!
*shrug*... guess i have the totally oposite outlook
than you, i've had quite a number of my patches go mainstream though
dude, the entire selinux thing is disliked by stacks of debian
maintainers because of the knock-on implications it has.
imagine what chaos would ensue if up until now, linux only had
a FAT filesystem and someone said "hey, there's this _great_ concept
it's called file ownership and file permissions, i've invented
something called an ext2 filesystem".
l.
--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl(a)lkcl.net </a> <br />
2:26 p.m.
On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
i think we need the input of more experienced people than us to
say why these associate things are needed.
It provides control over the set of files that can live in a given
filesystem, based on their security types (equivalence classes). As you
are now creating device types in a different filesystem type, further
allow rules are needed to allow that association.
a correct implementation of the
hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
operation (mount with a new context which would otherwise need to be
achieved with two commands: mount followed by restorecon)
The more important issue is that fscontext= lets you set the superblock
security context, not just the root directory context. restorecon can't
do that.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
3:02 p.m.
On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote:
On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
> i think we need the input of more experienced people than us to
> say why these associate things are needed.
It provides control over the set of files that can live in a given
filesystem, based on their security types (equivalence classes). As you
are now creating device types in a different filesystem type, further
allow rules are needed to allow that association.
> a correct implementation of the
> hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
> operation (mount with a new context which would otherwise need to be
> achieved with two commands: mount followed by restorecon)
The more important issue is that fscontext= lets you set the superblock
security context, not just the root directory context. restorecon can't
do that.
ah.
thanks for clarifying, steven.
l.
4:18 p.m.
This should be of great assistance with two home projects currently
and 1 work project due to the filesystem types. I am still working
through size issues and further locking down the images.
Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router
Project 2 = SE Linux image for Cisco 2501 Router
Project 3 = Debian Sarge Server build on SGI Octane with reiserfs (
Work for Network Management Server )
Thanks,
Jim McCullough
On Tue, 31 Aug 2004 21:02:10 +0100, Luke Kenneth Casson Leighton
<lkcl(a)lkcl.net> wrote:
On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote:
> On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
> > i think we need the input of more experienced people than us to
> > say why these associate things are needed.
>
> It provides control over the set of files that can live in a given
> filesystem, based on their security types (equivalence classes). As you
> are now creating device types in a different filesystem type, further
> allow rules are needed to allow that association.
>
> > a correct implementation of the
> > hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
> > operation (mount with a new context which would otherwise need to be
> > achieved with two commands: mount followed by restorecon)
>
> The more important issue is that fscontext= lets you set the superblock
> security context, not just the root directory context. restorecon can't
> do that.
ah.
thanks for clarifying, steven.
l.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo(a)tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
--
Jim McCullough
6:26 p.m.
well, the patch is at um.. oh no it's not... um, hang on...
yep, it's _now_ at http://hands.com/~lkcl/selinux/selinux-hooks.patch
On Tue, Aug 31, 2004 at 05:18:05PM -0400, Jim McCullough wrote:
This should be of great assistance with two home projects currently
and 1 work project due to the filesystem types. I am still working
through size issues and further locking down the images.
Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router
Project 2 = SE Linux image for Cisco 2501 Router
Project 3 = Debian Sarge Server build on SGI Octane with reiserfs (
Work for Network Management Server )
> > The more important issue is that fscontext= lets you set
the superblock
> > security context, not just the root directory context. restorecon can't
> > do that.
5:44 p.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Tue, Aug 31, 2004 at 08:18:10PM +0100, Luke Kenneth Casson Leighton was heard to
remark:
dude, the entire selinux thing is disliked by stacks of debian
maintainers because of the knock-on implications it has.
Totally off-topic remark, unrelated to anything, but I'm waiting
for somethig to compile :)
Every now and then, I look at SELinux, and I get scared away by its
complexity. This complexity makes it very hard to audit, and assure
oneself that its actually providing any real security, as opposed to
the illusion of security. During this email thread, there are
references to mysterious rules that neither party in the conversation
fully understands; this scares me.
Compare this to less complex security provided by e.g. the Linux
VServer project. VServer is intended to allow an ISP to pretend they
have a rack of 100 cpu's all running linux, when in fact they have just
one. The fact that it provides security is a side-effect; but its
far simpler, far easier to audit, and allows me to sleep at night.
Another example: Way back in the kernel-2.2 timeframe, I hacked on
something neat: 'LOMAC': if you came in from a network connection,
you lost permission to do almost anything, other than to e.g. webserve.
The system was simple, worked well, the kernel patches were easy to audit,
you could go home without worrying about priveledge escalation.
Compare that to this thread, where we are talking about atomic vs.
non-atomic restoration of context for udev-mounted temp file systems.
Shudder. This seems to be begging for an exploit to be discovered.
Are we sure that SELinux is really on the right track here?
--linas
9:23 a.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Tue, 31 Aug 2004, Linas Vepstas wrote:
Every now and then, I look at SELinux, and I get scared away by its
complexity. This complexity makes it very hard to audit, and assure
oneself that its actually providing any real security, as opposed to
the illusion of security. ...
Tough questions. Good questions!
Still, I do believe MAC has value in contrast to DAC.
But the opposing "flying buttress" to this is that it all
boils down to binary ... somewhere. And is THAT part isolated?
Compare this to less complex security provided by e.g. the Linux
VServer project. VServer is intended to allow an ISP to pretend they
have a rack of 100 cpu's all running linux, when in fact they have just
one. The fact that it provides security is a side-effect; but its
far simpler, far easier to audit, and allows me to sleep at night.
Ahhh... virtual machines. (And I don't mean Java.)
I'm thinking VMware and (esp) z/VM (IBM style mainframe).
Been using both or years, VMware since 1.0 beta and mainframe since ...
well ... I was pretty young at the time. But not for security per-se,
they have other interesting features. Linas' mention of VServer
and its side-effect security reminds me of something I read
in the anals of VM hisory:
http://vm.marist.edu/~vmshare/browse?fn=VMHIST07&ft=NOTE
(Stephen, Howard, and the rest and friends at the NSA
please take no offense. I found this terribly entertaining.)
Even from its earliest days, VM (CP) isolated each user, so:
"On another occasion we almost had an in-house protest.
Among the early users of CP-67/CMS were both the National
Security Agency and the CIA; the fact that the DAT hardware
isolated each user in his own address space was viewed as a
powerful system security feature. One time in 1970, I
think, the CIA sent two of their people to Cambridge to talk
about something that Ed Hendricks had developed or was
working on. In the atmosphere of the time, none of the
technical people at CSC, especially Ed, wanted to talk to
them at all! Ed stormed around the halls muttering "damned
spooks!" for half an hour or more before Craig Johnson and
Norm Rasmussen were able to coerce him into the meeting.
Even more amazing is that they were spooks; there was a man
and a woman, both of slightly below-average height, average
build, average everything! You could stand and talk
directly to them or study them for five minutes or more, but
if you turned around there was nothing to remember and
nothing to describe; they were effectively invisible."
Thanks to Lynn Wheeler for helping me dig this up.
-- R;
9:29 a.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
[ The CC list here is rather nuts, someone needs to trim it...]
On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote:
Every now and then, I look at SELinux, and I get scared away by its
complexity.
It is actually not that complicated, but if you're unfamiliar with
mandatory access control (as I was when I first started learning about
SELinux), it does require understanding some theory before you dive in.
This complexity makes it very hard to audit, and assure
oneself that its actually providing any real security, as opposed to
the illusion of security. During this email thread, there are
references to mysterious rules that neither party in the conversation
fully understands; this scares me.
Because two people in a thread don't understand SELinux, that means that
it's too complex? I can certainly find plenty of examples of people not
understanding Linux on linux-kernel; does that imply Linux is too
complex?
Compare this to less complex security provided by e.g. the Linux
VServer project. VServer is intended to allow an ISP to pretend they
have a rack of 100 cpu's all running linux, when in fact they have just
one.
VServer isn't solving the same problem as SELinux. VServer is really a
virtualization solution. For example, it would make sense to run *both*
a virtualization solution like VServer (or Xen, which looks more
promising), and SELinux at the same time. That way, if e.g. the bind
daemon running in one of the virtualized servers gets cracked, it
doesn't mean a compromise of the whole virtual server.
Now, you can use a virtualization technology as a primitive form of
separation by running e.g. your MTA in one virtual server, your name
server in another, etc. But that's rather painful, and is only an
approximation to least privilege.
Another example: Way back in the kernel-2.2 timeframe, I hacked on
something neat: 'LOMAC': if you came in from a network connection,
you lost permission to do almost anything, other than to e.g. webserve.
The system was simple, worked well, the kernel patches were easy to audit,
you could go home without worrying about priveledge escalation.
That's also a rather blunt tool; SELinux is much more flexible.
Compare that to this thread, where we are talking about atomic vs.
non-atomic restoration of context for udev-mounted temp file systems.
Shudder. This seems to be begging for an exploit to be discovered.
I doubt it. Files created in /dev should have a default type like
device_t which most domains will not have access to.
Are we sure that SELinux is really on the right track here?
Given the amount of research behind SELinux, and the amount of work
being done on it, I think so, yes.
12:25 p.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Wed, Sep 01, 2004 at 10:29:34AM -0400, Colin Walters was heard to remark:
[ The CC list here is rather nuts, someone needs to trim it...]
On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote:
> Every now and then, I look at SELinux, and I get scared away by its
> complexity.
It is actually not that complicated, but if you're unfamiliar with
mandatory access control (as I was when I first started learning about
SELinux), it does require understanding some theory before you dive in.
Hmm, I thought I understood MAC; I was refering to the large numbers of
rules in SELinux. Its not obvious (to me) that there isn't a path
through those rules that allows privledge escalation.
For example: and correct me if I'm wrong, but its quite possible to
write a complex rule set that intentionally leaves 'holes' allowing
for priveledge escalation. Thus, by extrapolation, its quite possible
to write a set of rules that accidentally do the same. When one is
presented with a set of rules, how does one know that they don't have a
hole? Answer: one audits the rules. Unfortunately, there are a lot
of rules: last time I looked at one of the config files, it was
thousands of lines long. Thus, a short, simple audit performed by
one person seems out of the question.
Now, as to auditing...
it's too complex? I can certainly find plenty of examples of
people not
understanding Linux on linux-kernel; does that imply Linux is too
complex?
We've had a fair number of "eyeballs" read the linux kernel, and thus
base our trust in its security on that. However, the SELinux rules
are unlike the kernel in an important way: they are config files.
This allows allows some anonymous fedora/debian/gentoo maintainer
to do something dumb like "gee, my USB camera doesn't work with udev,
but then when I change this selinux rule, it does", and poof, you've
lost the security. I'm presuming that this kind of mucking around is
far more common than altering lines of source in the kernel that weaken
security. But I base my presumption on real life: go to any LUG,
hang out with any sysadmin long enough, and you will see them make
changes to config files that are dangerous if not outright incorrect.
Sysadmins are, as a species, people who work with incomplete knowledge
of the systems they administer.
> Compare this to less complex security provided by e.g. the Linux
> VServer project.
VServer isn't solving the same problem as SELinux.
Yes, that's right. I did try to point that out ...
That way, if e.g. the bind
daemon running in one of the virtualized servers gets cracked, it
doesn't mean a compromise of the whole virtual server.
No... If the bind deamon gets cracked, it doesn't compromise the 'whole';
it only compromises root and anything else running in that context.
It does not (in theory) compromise root in the other contexts. In other
words, one of the servers could be 0wned by someone truly hostile,
while the 'whole' remains (theoretically) safe.
Now, you can use a virtualization technology as a primitive form of
separation by running e.g. your MTA in one virtual server, your name
server in another, etc. But that's rather painful, and is only an
approximation to least privilege.
Yes, this is exactly what I'm thinking of. But its not painful,
it solves 90% or 100% of the needs of a 'typical' ISP/ASP/web server
admin. Yes, this is indeed a blunt tool... see below:
> Another example: Way back in the kernel-2.2 timeframe, I hacked
on
> something neat: 'LOMAC': if you came in from a network connection,
> you lost permission to do almost anything, other than to e.g. webserve.
> The system was simple, worked well, the kernel patches were easy to audit,
> you could go home without worrying about priveledge escalation.
That's also a rather blunt tool; SELinux is much more flexible.
What I'm proposing here is that bluntness can be traded for increased
assurances and increased ability to audit the code for "correctness".
Yes, SELinux is far more flexible; but this is exactly what scares me.
I once thought about re-implementing LoMAC as a ruleset atop of SELinux.
I'm pretty sure that this is possible, but I started thinking that the
complexity of the ruleset may introduce holes that voids the effort.
And that thought disturbed me.
Along with Lomac's 'bluntness' comes 'zero configurability': its
something that could be installed on the proverbial 'Grandma's Linux
desktop', and provide additional security without causing pain.
With selinux, its not only not zero-conf, but its also not clear
(to me) if the rulesets that install with debian/fedora/etc. actually
provide any additonal security at all against network breakins.
If the rulesets do indeed provide this protection, then there is a
perception/marketing problem: people like me "don't get it" from
just skimming the selinux web pages. I'd prefer to get all the
benefits of SELinux without having to RTFM.
--linas
10:34 a.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
Linas Vepstas linas-at-austin.ibm.com |fedora| wrote:
Its not obvious (to me) that there isn't a path
through those rules that allows privledge escalation.
Unfortunately, there are a lot
of rules: last time I looked at one of the config files, it was
thousands of lines long. Thus, a short, simple audit performed by
one person seems out of the question.
Has anyone been working on a graphical representation to the rules and
current labeling for visualizing a rulebase/system/runtime
configuration? It seems to me that for Fedora/SELinux to go mainstream
some form of a visual auditing tool would be required. Being able to
take some entity such as a file system or running process and visually
displaying the access permissions in the context of privileges granted
to a user or process would go a long way towards SE's mainstream
adoption. If such a tool were to also help the admin rewrite the rules
based on changes to entities while walking down the directory tree it
would put SELinux in a much better position for the average admin. Of
course such a tool would require careful though in the design due to the
desired separation of duties (e.g. auditing vs. administration privs)
and the rule definition v.s. Application thereof v.s. the runtime
contexts for a given user/process.
I have to admit that I have been merely lurking here for a while and
have not yet installed SELinux on anything as of yet. My “lurking”
rather than “doing” is due mostly to my time limitations, and the
thought of making my system unusable for my real work because I would
have no way to understand all the rules in such short order. If I could
see the effects of making a given change (e.g. color coding, symbolic
representation) to the system before actually applying that change
(relabeling) then I would be much less hesitant to convert everything
over to FC2/3 with SELinux as my primary reason for migrating. From
what I can see so far SELinux is great stuff, and I praise everyone
working on it for such dedicated work! Thanks to all.
11:10 a.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Wed, 2004-09-01 at 13:25, Linas Vepstas wrote:
Hmm, I thought I understood MAC; I was refering to the large numbers
of
rules in SELinux. Its not obvious (to me) that there isn't a path
through those rules that allows privledge escalation.
For example: and correct me if I'm wrong, but its quite possible to
write a complex rule set that intentionally leaves 'holes' allowing
for priveledge escalation. Thus, by extrapolation, its quite possible
to write a set of rules that accidentally do the same. When one is
presented with a set of rules, how does one know that they don't have a
hole? Answer: one audits the rules. Unfortunately, there are a lot
of rules: last time I looked at one of the config files, it was
thousands of lines long. Thus, a short, simple audit performed by
one person seems out of the question.
The complexity of the rules reflect the complexity of the existing Linux
system and its interactions; SELinux didn't introduce that complexity -
SELinux just enables you to control what happens in that complex
system. No criticism intended of Linux; the same would apply to any
mainstream operating system, and the complexity just reflects real world
requirements. And you do have the option of reducing the visible
complexity based on your security goals; if you don't care about the
interactions among a set of processes/resources, you fold the domain and
type space accordingly. The targeted policy is an example of doing that
to an extreme.
Analysis of that complexity _does_ require automated tools, and such
tools exist. apol (yum install setools setools-gui) provides support
for analysis, including domain transitions and information flow. slat
(available from the NSA SELinux site or MITRE) does security goal
checking using a model checker. Gokyo from IBM Watson (which AFAIK is
unfortunately not released publically yet, perhaps you could encourage
that to happen) analyzes against Biba integrity constraints and
identifies exceptions for further examination.
However, the SELinux rules
are unlike the kernel in an important way: they are config files.
This allows allows some anonymous fedora/debian/gentoo maintainer
to do something dumb like "gee, my USB camera doesn't work with udev,
but then when I change this selinux rule, it does", and poof, you've
lost the security.
The policy maintainers for the various distros are not anonymous and
appear to take their work quite seriously; rejecting policy changes
despite a reduction in functionality is not uncommon. You seem to be
assuming that policy for each package is maintained by the individual
package maintainers; that isn't the case, and likely never will be.
Ditto for sysadmins; most of them should never touch policy at all.
What I'm proposing here is that bluntness can be traded for
increased
assurances and increased ability to audit the code for "correctness".
Yes, SELinux is far more flexible; but this is exactly what scares me.
Reality is complex. Deal with it. Being confident in the correctness
of an inadequate security model doesn't help much.
I once thought about re-implementing LoMAC as a ruleset atop of
SELinux.
I'm pretty sure that this is possible, but I started thinking that the
complexity of the ruleset may introduce holes that voids the effort.
And that thought disturbed me.
It isn't actually possible to implement LOMAC via SELinux, but that's
another topic.
Along with Lomac's 'bluntness' comes 'zero
configurability': its
something that could be installed on the proverbial 'Grandma's Linux
desktop', and provide additional security without causing pain.
Until Grandma wants to do useful work. Simple security models are nice
to look at, but they don't capture the behavior of real systems, and it
doesn't matter that the model is "secure"; you just break one of the
trusted subjects authorized to override the security model in order to
get the real work done. SELinux policy may look weaker to you, but it
actually represents what is being allowed in the system; no exceptions.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
11:58 a.m.
New subject: unsubscribe
-----Original Message-----
From: fedora-selinux-list-bounces(a)redhat.com
[mailto:fedora-selinux-list-bounces@redhat.com] On Behalf Of Stephen Smalley
Sent: Thursday, September 02, 2004 11:11 AM
To: Fedora SELinux support list for users & developers.
Cc: linux-hotplug-devel(a)lists.sourceforge.net; SELinux; Bill Nottingham;
Colin Walters; Nigel Kukard; harald(a)redhat.com
Subject: Re: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Wed, 2004-09-01 at 13:25, Linas Vepstas wrote:
Hmm, I thought I understood MAC; I was refering to the large numbers
of
rules in SELinux. Its not obvious (to me) that there isn't a path
through those rules that allows privledge escalation.
For example: and correct me if I'm wrong, but its quite possible to
write a complex rule set that intentionally leaves 'holes' allowing
for priveledge escalation. Thus, by extrapolation, its quite possible
to write a set of rules that accidentally do the same. When one is
presented with a set of rules, how does one know that they don't have a
hole? Answer: one audits the rules. Unfortunately, there are a lot
of rules: last time I looked at one of the config files, it was
thousands of lines long. Thus, a short, simple audit performed by
one person seems out of the question.
The complexity of the rules reflect the complexity of the existing Linux
system and its interactions; SELinux didn't introduce that complexity -
SELinux just enables you to control what happens in that complex
system. No criticism intended of Linux; the same would apply to any
mainstream operating system, and the complexity just reflects real world
requirements. And you do have the option of reducing the visible
complexity based on your security goals; if you don't care about the
interactions among a set of processes/resources, you fold the domain and
type space accordingly. The targeted policy is an example of doing that
to an extreme.
Analysis of that complexity _does_ require automated tools, and such
tools exist. apol (yum install setools setools-gui) provides support
for analysis, including domain transitions and information flow. slat
(available from the NSA SELinux site or MITRE) does security goal
checking using a model checker. Gokyo from IBM Watson (which AFAIK is
unfortunately not released publically yet, perhaps you could encourage
that to happen) analyzes against Biba integrity constraints and
identifies exceptions for further examination.
However, the SELinux rules
are unlike the kernel in an important way: they are config files.
This allows allows some anonymous fedora/debian/gentoo maintainer
to do something dumb like "gee, my USB camera doesn't work with udev,
but then when I change this selinux rule, it does", and poof, you've
lost the security.
The policy maintainers for the various distros are not anonymous and
appear to take their work quite seriously; rejecting policy changes
despite a reduction in functionality is not uncommon. You seem to be
assuming that policy for each package is maintained by the individual
package maintainers; that isn't the case, and likely never will be.
Ditto for sysadmins; most of them should never touch policy at all.
What I'm proposing here is that bluntness can be traded for
increased
assurances and increased ability to audit the code for "correctness".
Yes, SELinux is far more flexible; but this is exactly what scares me.
Reality is complex. Deal with it. Being confident in the correctness
of an inadequate security model doesn't help much.
I once thought about re-implementing LoMAC as a ruleset atop of
SELinux.
I'm pretty sure that this is possible, but I started thinking that the
complexity of the ruleset may introduce holes that voids the effort.
And that thought disturbed me.
It isn't actually possible to implement LOMAC via SELinux, but that's
another topic.
Along with Lomac's 'bluntness' comes 'zero
configurability': its
something that could be installed on the proverbial 'Grandma's Linux
desktop', and provide additional security without causing pain.
Until Grandma wants to do useful work. Simple security models are nice
to look at, but they don't capture the behavior of real systems, and it
doesn't matter that the model is "secure"; you just break one of the
trusted subjects authorized to override the security model in order to
get the real work done. SELinux policy may look weaker to you, but it
actually represents what is being allowed in the system; no exceptions.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
12:29 p.m.
New subject: Lomac questions [was Re: [OT] SELinux vs. other systems]
Hi Stephen,
Excellent answer... its been too long since I've played with selinux.
I'll try again.
> I once thought about re-implementing LoMAC as a ruleset atop of
SELinux.
> I'm pretty sure that this is possible, but I started thinking that the
> complexity of the ruleset may introduce holes that voids the effort.
> And that thought disturbed me.
It isn't actually possible to implement LOMAC via SELinux, but that's
another topic.
Hmm, why not?
> Along with Lomac's 'bluntness' comes 'zero
configurability': its
> something that could be installed on the proverbial 'Grandma's Linux
> desktop', and provide additional security without causing pain.
Until Grandma wants to do useful work. Simple security models are nice
to look at, but they don't capture the behavior of real systems, and it
doesn't matter that the model is "secure"; you just break one of the
trusted subjects authorized to override the security model in order to
get the real work done. SELinux policy may look weaker to you, but it
actually represents what is being allowed in the system; no exceptions.
I don't quite understand this. I'm currently running Lomac on one of
my servers, and I can get work done. It seems to be usable, even if
it makes some operations, like software install, harder.
I'm not sure what you mean by 'break a trusted subject'. If you mean
'ssh is trusted, so if ssh is broken, all hope is lost', then yes.
But surely selinux has trusted subjects that may not be trustworthy?
If you mean 'lomac provides explicit tools that allow a sysadmin
to manually move a file from lower to higher trust domains', then,
well, I'm also confused. Surely selinux also has a way to start
with something untrusted, and then raise its level ... e.g. to
install software downloaded from the net.
Is the 'broken-ness' the fact that grandma failed to run an anti-virus
scanner and verify checksums, yada yada, before elevating the
priveldge on the downloaded software?
--linas
3:05 p.m.
New subject: Lomac questions [was Re: [OT] SELinux vs. other systems]
On Thu, Sep 02, 2004 at 12:29:07PM -0500, Linas Vepstas wrote:
Is the 'broken-ness' the fact that grandma failed to run an
anti-virus
scanner and verify checksums, yada yada, before elevating the
priveldge on the downloaded software?
[this is all with the strict policy 1.14 mostly sortof btw]
i've installed clamav, spamassassin, razor and pyzor.
oh, and freshclam.
i then found a little script called clamassassin [google], i then
searched [google] for some advice on how to set up kmail filters.
kmail, the clamassassin script and spamc all run under the user
context.
the user context is given the right to bind to servers.
spamd and clamd both run as servers: they have their own
policies that restrict their operation to what is known
that they presently do, but they are allowed to listen to
incoming requests [from spamc and the clamassassin script
respectively.]
selinux doesn't in the _slightest_ bit get in the way.
the only thing that i did find is that razor is a complete pain.
it endeavours to write log files into /root/razor.log, /tmp/razor.log,
/razor.log, it's a pain, and selinux is _exactly_ the sort of thing
that can detect - and stop! - this behaviour.
pyzor appears to be a lot less haphazard.
also nobody else appears to have tried to run freshclam [automatic
update script] before now, so i had to hack the clamav.te policy
a bit to get it to run.
l.
7:15 a.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Wed, 1 Sep 2004 08:44, Linas Vepstas <linas(a)austin.ibm.com> wrote:
Every now and then, I look at SELinux, and I get scared away by its
complexity. This complexity makes it very hard to audit, and assure
What auditing are you referring to? Kernel code, application code, or policy?
The application code is not overly complex. The kernel code is as good as
such code can be. Tresys http://www.tresys.com/ are developing tools for
auditing SE Linux policy.
oneself that its actually providing any real security, as opposed to
the illusion of security. During this email thread, there are
references to mysterious rules that neither party in the conversation
fully understands; this scares me.
Which mysterious rules are you referring to?
Compare that to this thread, where we are talking about atomic vs.
non-atomic restoration of context for udev-mounted temp file systems.
Shudder. This seems to be begging for an exploit to be discovered.
Are we sure that SELinux is really on the right track here?
The original udev implementation had the device nodes relabelled after
creation. As of recent times (since 2002) the default SE Linux policy has
denied almost all domains (only two system domains) access to device nodes
labelled as device_t. This means that there is no window of opportunity for
an attacker to access a device before it is correctly labelled.
The worst race condition attack would be a DOS attack, cause an access at the
wrong time and have it be denied when otherwise it would be permitted. This
is the least serious of all possible problems related to device labelling.
--
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
12:07 p.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Thu, Sep 02, 2004 at 10:15:20PM +1000, Russell Coker was heard to remark:
On Wed, 1 Sep 2004 08:44, Linas Vepstas <linas(a)austin.ibm.com>
wrote:
> Every now and then, I look at SELinux, and I get scared away by its
> complexity. This complexity makes it very hard to audit, and assure
What auditing are you referring to? Kernel code, application code, or policy?
policy.
> oneself that its actually providing any real security, as
opposed to
> the illusion of security. During this email thread, there are
> references to mysterious rules that neither party in the conversation
> fully understands; this scares me.
Which mysterious rules are you referring to?
I wasn't refering to them, the posters to the thread were. Unfortunately,
I've already deleted those emails.
labelled as device_t. This means that there is no window of
opportunity for
an attacker to access a device before it is correctly labelled.
OK.
Well, here's another idle question, again off-topic: Does SELinux provide
any sort of assurances that storage media weren't tampered with between
reboots?
For example, with BIOS/firmware getting more sophisticated over time,
there's potential for an attacker to break in, remotely, into
bios/firmware, shortly before booting into the OS, and then alter
disk contents. Yes, I know this is far-fetched, but was just curious.
What got me going on that thread was thinking about udev/hotplug again:
with devices coming and going, disappearing and re-appearing, it isn't
obvious that there wasn't tampering while the device was gone.
Again, excuse me if this sounds naive, un-informed or far-fetched,
or terribly off-topic, but: In ye olden days, viruses spread through
diskettes. These days, we're plugging-n-playing usb keychains,
cameras, ipods, bluetooth this-n-that; although I haven't heard of
attacks carried out through these media, its not obivious that these
couldn't be carriers for an attack.
--linas
3:49 a.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Fri, 3 Sep 2004 03:07, Linas Vepstas <linas(a)austin.ibm.com> wrote:
Well, here's another idle question, again off-topic: Does SELinux
provide
any sort of assurances that storage media weren't tampered with between
reboots?
No, that is outside the scope of the SE Linux project.
I am one of the many people in Red Hat who are involved in working on crypto
block device support. One of my own systems has a root file system that is
AES encrypted with the kernel and initrd (which includes the decryption key)
on removable media. Eventually I want to see this become a standard feature
of Fedora, maybe in FC4. I think it will address most of what you want in
this regard.
Note that the NSA guys do not talk to me about any security stuff, so I don't
expect them to have any involvement in such things.
For example, with BIOS/firmware getting more sophisticated over
time,
there's potential for an attacker to break in, remotely, into
bios/firmware, shortly before booting into the OS, and then alter
disk contents. Yes, I know this is far-fetched, but was just curious.
When booting from removable media that contains the decryption key the attack
scenario would be to replace the BIOS with one that sends everything it reads
from disk (IE everything that the boot loader reads) over an Ethernet
interface.
A trojan BIOS that modifies the kernel during the boot load process to
introduce a security hole would be doable if you have adequate resources.
--
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
5:47 a.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
Russell Coker wrote:
When booting from removable media that contains the decryption key
the attack
scenario would be to replace the BIOS with one that sends everything it reads
from disk (IE everything that the boot loader reads) over an Ethernet
interface.
A trojan BIOS that modifies the kernel during the boot load process to
introduce a security hole would be doable if you have adequate resources.
there is a second option (also bios and startup related):
you can put an additional pci-extension-bios to any pci-card which have
a own pci-extension-bios for setting up its hardware, the chips are
usaly 64k but not fully used (graficcard, networkcard, ...) and the
point is, the standard allows you to put several
pci-extension-bios-images into one of such eeproms which just point to
each other and get called through the main-bios
so its not really necessary to exchange the system bios, get your hands
on a pci-card with a extension-bios may be enough... so keep your eyes
open if you change hardware ;)
and this is working practical, i have written a pci-extension-bios which
actuly was sitting at (in this case) the network card for
reading/setting bios-settings (nvram) during boot-up process at the
serial port some years ago (was for some semiautomatic setting up
process of 'black-box' hardware with no keyboard monitors attached to
it) ok - second problem here, would be getting the code surviving in ram
the boot-up sequence of the operating system, but i'm sure this won't be
any problem for some ppl with the necessary skills
i'm not sure about the pci-x-standard, but i think this could be working
similar
greetings
dalini
5:54 a.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
Russell Coker wrote:
When booting from removable media that contains the decryption key
the attack
scenario would be to replace the BIOS with one that sends everything it reads
from disk (IE everything that the boot loader reads) over an Ethernet
interface.
A trojan BIOS that modifies the kernel during the boot load process to
introduce a security hole would be doable if you have adequate resources.
there is a second option (also bios and startup related):
you can put an additional pci-extension-bios to any pci-card which have
a own pci-extension-bios for setting up its hardware, the chips are
usaly 64k but not fully used (graficcard, networkcard, ...) and the
point is, the standard allows you to put several
pci-extension-bios-images into one of such eeproms which just point to
each other and get called through the main-bios
so its not really necessary to exchange the system bios, get your hands
on a pci-card with a extension-bios may be enough... so keep your eyes
open if you change hardware ;)
and this is working practical, i have written a pci-extension-bios which
actuly was sitting at (in this case) the network card for
reading/setting bios-settings (nvram) during boot-up process at the
serial port some years ago (was for some semiautomatic setting up
process of 'black-box' hardware with no keyboard monitors attached to
it) ok - second problem here, would be getting the code surviving in ram
the boot-up sequence of the operating system, but i'm sure this won't be
any problem for some ppl with the necessary skills
i'm not sure about the pci-x-standard, but i think this could be working
similar
greetings
dalini
4:01 a.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Sat, 4 Sep 2004 20:54, Ives Steglich <fedora-se-linux(a)dalini.de> wrote:
there is a second option (also bios and startup related):
you can put an additional pci-extension-bios to any pci-card which have
a own pci-extension-bios for setting up its hardware, the chips are
usaly 64k but not fully used (graficcard, networkcard, ...) and the
Good point. However one limitation of this is that it won't work so well for
laptops.
The idea of replacing a BIOS was first suggested to me after a discussion of
an advertised security product which had some very suspect claims about it's
performance. The claim that it could survive a re-install of Windows seemed
difficult to believe and a modified BIOS was the only suggestion of a
possible way of doing it.
second problem here, would be getting the code surviving in ram
the boot-up sequence of the operating system, but i'm sure this won't be
any problem for some ppl with the necessary skills
That is solvable too. It would have to decompress the kernel image, modify
the kernel code in some subtle way (EG making some security check function in
the kernel be a noop), re-compress the kernel image and then present it to
the boot loader upon read requests. It's difficult, but not impossible.
--
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
12:19 p.m.
New subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Thu, Sep 02, 2004 at 10:15:20PM +1000, Russell Coker wrote:
> Compare that to this thread, where we are talking about atomic
vs.
> non-atomic restoration of context for udev-mounted temp file systems.
> Shudder. This seems to be begging for an exploit to be discovered.
> Are we sure that SELinux is really on the right track here?
The original udev implementation had the device nodes relabelled after
creation. As of recent times (since 2002) the default SE Linux policy has
denied almost all domains (only two system domains) access to device nodes
labelled as device_t. This means that there is no window of opportunity for
an attacker to access a device before it is correctly labelled.
The worst race condition attack would be a DOS attack, cause an access at the
wrong time and have it be denied when otherwise it would be permitted. This
is the least serious of all possible problems related to device labelling.
... and with the use of matchpathcon() followed by setfscreatecon(),
it isn't even that: inode, symlink and directory
creation-plus-filecontext-setting are done as an atomic operation.
problem goes away.
the _old_ selinux udev support (0.024), on the other hand, suffered
from the big-deal-DOS-attack that russell describes above.
l.
7168
days inactive
7177
days old
selinux@lists.fedoraproject.org
29 comments
12 participants
participants (12)
-
Colin Walters -
dalini -
Fraser Cringan -
Ives Steglich -
Jim McCullough -
Linas Vepstas -
Luke Kenneth Casson Leighton -
Nigel Kukard -
Richard Troth -
Russell Coker -
Stephen Smalley -
Steve Coleman