All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

WARNING: multiple messages have this Message-ID (diff)
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 18:46:35 +0200	[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 --]

  reply	other threads:[~2004-08-31 16:46 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-30 17:37 [idea] udev + selinux Nigel Kukard
2004-08-30 17:37 ` Nigel Kukard
2004-08-30 20:31 ` Luke Kenneth Casson Leighton
2004-08-30 20:31   ` Luke Kenneth Casson Leighton
2004-08-31  5:02   ` Nigel Kukard
2004-08-31  5:02     ` Nigel Kukard
2004-08-31  9:49     ` Luke Kenneth Casson Leighton
2004-08-31  9:49       ` Luke Kenneth Casson Leighton
2004-08-31 10:27       ` Nigel Kukard
2004-08-31 10:27         ` Nigel Kukard
2004-08-31 12:46         ` Luke Kenneth Casson Leighton
2004-08-31 12:46           ` Luke Kenneth Casson Leighton
2004-08-31 11:26       ` 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:07   ` Luke Kenneth Casson Leighton
2004-08-31 16:46   ` Nigel Kukard [this message]
2004-08-31 16:46     ` Nigel Kukard
2004-08-31 19:18     ` Luke Kenneth Casson Leighton
2004-08-31 19:18       ` Luke Kenneth Casson Leighton
2004-08-31 19:26       ` Stephen Smalley
2004-08-31 19:26         ` Stephen Smalley
2004-08-31 20:02         ` Luke Kenneth Casson Leighton
2004-08-31 20:02           ` Luke Kenneth Casson Leighton
2004-08-31 21:18           ` Jim McCullough
2004-08-31 21:18             ` Jim McCullough
2004-08-31 23:26             ` Luke Kenneth Casson Leighton
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 14:23           ` Richard Troth
2004-09-01 14:29         ` Colin Walters
2004-09-01 17:25         ` Linas Vepstas
2004-09-02 16:10           ` Stephen Smalley
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 17:29               ` Linas Vepstas
2004-09-02 20:05               ` Luke Kenneth Casson Leighton
2004-09-02 20:05                 ` Luke Kenneth Casson Leighton
2004-09-02 12:15         ` [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] Russell Coker
2004-09-02 17:07           ` Linas Vepstas
2004-09-04  8:49             ` Russell Coker
2004-09-02 17:19           ` 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 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.