linux-hotplug.vger.kernel.org archive mirror
 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 05:02:52 +0000	[thread overview]
Message-ID: <20040831050252.GF10151@lbsd.net> (raw)
In-Reply-To: <20040830203140.GB31497@lkcl.net>

[-- Attachment #1: Type: text/plain, Size: 4046 bytes --]

>  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@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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-08-31  5:02 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 [this message]
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
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=20040831050252.GF10151@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).