All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Nigel Kukard <nkukard@lbsd.net>
Cc: 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 19:18:10 +0000	[thread overview]
Message-ID: <20040831191809.GC4375@lkcl.net> (raw)
In-Reply-To: <20040831164635.GK10151@lbsd.net>

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@lkcl.net </a> <br />



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

WARNING: multiple messages have this Message-ID (diff)
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Nigel Kukard <nkukard@lbsd.net>
Cc: 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 20:18:10 +0100	[thread overview]
Message-ID: <20040831191809.GC4375@lkcl.net> (raw)
In-Reply-To: <20040831164635.GK10151@lbsd.net>

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@lkcl.net </a> <br />


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2004-08-31 19:18 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
2004-08-31 16:46     ` Nigel Kukard
2004-08-31 19:18     ` Luke Kenneth Casson Leighton [this message]
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=20040831191809.GC4375@lkcl.net \
    --to=lkcl@lkcl.net \
    --cc=SELinux@tycho.nsa.gov \
    --cc=fedora-selinux-list@redhat.com \
    --cc=harald@redhat.com \
    --cc=linux-hotplug-devel@lists.sourceforge.net \
    --cc=nkukard@lbsd.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.