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 --]
next prev parent 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).