From: Chris Richards <gizmo@giz-works.com>
To: gentoo-hardened@lists.gentoo.org
Subject: [gentoo-hardened] UDEV AVC Denials on with strict SELinux policy
Date: Thu, 10 Dec 2009 20:41:44 -0600 [thread overview]
Message-ID: <4B21B168.3030703@giz-works.com> (raw)
I'm seeing some AVC denials that don't make any sense to me.
When I boot the system, I see the following on my console:
* Mounting /dev ... [ok]
/etc/init.d/udev-mount: line 63: /dev/null: Permission denied
/etc/init.d/udev: line 69: /dev/null: Permission denied
* Starting udevd ... [ok]
* Populating /dev with existing devices through uevents ... [ok]
* Waiting for uevents to be processed ...
error sending message: Permission denied [ok]
error sending message: Permission denied
udevadm[601]: error sending message: Permission denied
/var/log/dmesg shows the following:
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
type=1400 audit(1260416495.426:3): avc: denied { write } for pid=461
comm="bash" name="null" dev=tmpfs ino=1367
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:device_t
tclass=chr_file
type=1400 audit(1260416495.640:4): avc: denied { read write } for
pid=470 comm="write_root_link" name="tty" dev=tmpfs ino=1366
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:device_t
tclass=chr_file
type=1400 audit(1260416495.640:5): avc: denied { read write } for
pid=470 comm="write_root_link" name="console" dev=tmpfs ino=1364
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:device_t
tclass=chr_file
type=1400 audit(1260416495.695:6): avc: denied { read } for pid=471
comm="udevadm" name="file_contexts" dev=sda3 ino=737895
scontext=system_u:system_r:initrc_t
tcontext=root:object_r:file_context_t tclass=file
type=1400 audit(1260416495.736:7): avc: denied { write } for pid=475
comm="bash" name="null" dev=tmpfs ino=1367
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:device_t
tclass=chr_file
udev: starting version 146
type=1400 audit(1260416496.041:8): avc: denied { read } for pid=479
comm="udevadm" name="file_contexts" dev=sda3 ino=737895
scontext=system_u:system_r:initrc_t
tcontext=root:object_r:file_context_t tclass=file
type=1400 audit(1260416496.057:9): avc: denied { read write } for
pid=481 comm="modprobe" path="/dev/null" dev=tmpfs ino=1367
scontext=system_u:system_r:insmod_t tcontext=system_u:object_r:device_t
tclass=chr_file
type=1400 audit(1260416496.057:10): avc: denied { read write } for
pid=481 comm="modprobe" path="/dev/null" dev=tmpfs ino=1367
scontext=system_u:system_r:insmod_t tcontext=system_u:object_r:device_t
tclass=chr_file
type=1400 audit(1260416496.057:11): avc: denied { read write } for
pid=481 comm="modprobe" path="/dev/null" dev=tmpfs ino=1367
scontext=system_u:system_r:insmod_t tcontext=system_u:object_r:device_t
tclass=chr_file
If I'm reading these right, then /dev/null, /dev/tty, /dev/console all
have the wrong context: device_t.
Thing is, they don't:
/dev/null is null_device_t, /dev/tty is devtty_t, /dev/console is
console_device_t verified for both udev mounted and static dev mounted.
The denial on file_contexts I don't understand, unless there is no rule
to transistion from initrc_t to file_contexts_t.
Can any one offer any guidance? I'm suspicious of some sort of race
condition, given where these errors are being generated, but I don't know.
Thanks,
Chris
reply other threads:[~2009-12-11 4:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4B21B168.3030703@giz-works.com \
--to=gizmo@giz-works.com \
--cc=gentoo-hardened@lists.gentoo.org \
/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