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: Mon, 30 Aug 2004 20:31:40 +0000	[thread overview]
Message-ID: <20040830203140.GB31497@lkcl.net> (raw)
In-Reply-To: <20040830173744.GD10151@lbsd.net>

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@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: Mon, 30 Aug 2004 21:31:40 +0100	[thread overview]
Message-ID: <20040830203140.GB31497@lkcl.net> (raw)
In-Reply-To: <20040830173744.GD10151@lbsd.net>

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@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-30 20:31 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 [this message]
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
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=20040830203140.GB31497@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.