From: Nigel Kukard <nkukard@lbsd.net>
To: linux-hotplug-devel@lists.sourceforge.net,
SELinux <SELinux@tycho.nsa.gov>,
"Fedora SELinux support list for users & developers."
<fedora-selinux-list@redhat.com>,
harald@redhat.com, Bill Nottingham <notting@redhat.com>
Subject: Re: [idea] udev + selinux
Date: Tue, 31 Aug 2004 16:46:35 +0000 [thread overview]
Message-ID: <20040831164635.GK10151@lbsd.net> (raw)
In-Reply-To: <20040831160750.GM11456@lkcl.net>
[-- Attachment #1: Type: text/plain, Size: 3766 bytes --]
> 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@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.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-08-31 16:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-30 17:37 [idea] udev + selinux Nigel Kukard
2004-08-30 20:31 ` Luke Kenneth Casson Leighton
2004-08-31 5:02 ` Nigel Kukard
2004-08-31 9:49 ` Luke Kenneth Casson Leighton
2004-08-31 10:27 ` Nigel Kukard
2004-08-31 12:46 ` Luke Kenneth Casson Leighton
2004-08-31 11:26 ` Luke Kenneth Casson Leighton
2004-08-31 16:07 ` Luke Kenneth Casson Leighton
2004-08-31 16:46 ` Nigel Kukard [this message]
2004-08-31 19:18 ` Luke Kenneth Casson Leighton
2004-08-31 19:26 ` Stephen Smalley
2004-08-31 20:02 ` Luke Kenneth Casson Leighton
2004-08-31 21:18 ` Jim McCullough
2004-08-31 23:26 ` Luke Kenneth Casson Leighton
2004-08-31 22:44 ` [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] Linas Vepstas
2004-09-01 14:23 ` Richard Troth
2004-09-01 17:25 ` Linas Vepstas
2004-09-02 16:10 ` Stephen Smalley
2004-09-02 17:29 ` Lomac questions [was Re: [OT] SELinux vs. other systems] Linas Vepstas
2004-09-02 20:05 ` Luke Kenneth Casson Leighton
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=20040831164635.GK10151@lbsd.net \
--to=nkukard@lbsd.net \
--cc=SELinux@tycho.nsa.gov \
--cc=fedora-selinux-list@redhat.com \
--cc=harald@redhat.com \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=notting@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).