Package: linux-image-2.6.32-3-686-bigmem
Severity: normal
Hello.
To reproduce the bug you will need some means for denying root access to
(possibly unmounted) devtmpfs filesystem.
This is easily achievable with SELinux, for example.
Required: kernel_t should be denied access to the devtmpfs fs_con type.
Debian's selinux-policy-default as of 2:0.2.20091117-2 version
provides default context for devtmpfs filesystem as system_u:object_r:tmpfs_t:s0
and contains no access rules for kernel_t to create special device nodes and
directories there, also kernel_t is not a permissive domain.
linux-image-2.6.32-3-686-bigmem as of 2.6.32-9 have devtmpfs enabled, but
userspace does not use it, so it does not get mounted and correctly labelled.
That would not be a problem if devtmpfs code would be bug-free, but it seems
that it is not prepared to see ENOPERM from vfs helpers, so that all manifests
as inability to boot with SELinux enabled and in enforced mode.
On first access to (unused and unbound) virtual console audit this (in
permissive mode):
type=AVC msg=audit(1272355156.238:105): avc: denied { search } for
pid=1686 comm="getty" name="/" dev=devtmpfs ino=4
scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
tclass=dir
type=AVC msg=audit(1272355156.238:105): avc: denied { write } for pid=1686
comm="getty" name="/" dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1272355156.238:105): avc: denied { add_name } for
pid=1686 comm="getty" name="vcs4" scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1272355156.238:105): avc: denied { create } for
pid=1686 comm="getty" name="vcs4" scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file
or when booted into single user mode without getty and with sulogin on
/dev/console (in permissive mode)
# echo > /dev/tty2
type=AVC msg=audit(1272355319.117:102): avc: denied { search } for
pid=1668 comm="getty" name="/" dev=devtmpfs ino=4
scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
tclass=dir
type=AVC msg=audit(1272355319.117:102): avc: denied { write } for pid=1668
comm="getty" name="/" dev=devtmpfs ino=4 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1272355319.117:102): avc: denied { add_name } for
pid=1668 comm="getty" name="vcs2" scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
type=AVC msg=audit(1272355319.117:102): avc: denied { create } for
pid=1668 comm="getty" name="vcs2" scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file
If booted in enforced mode, or just switched to enforced, any command, that
access unused (unbound) VTs
hangs the console totally. No VT switching or scrolling is possible,
ctrl-alt-del is not received,
however Sysrq-b reboots machine after a pause.
I believe, that nevertheless this denials may be fixed by writing an
appropriate SELinux module,
by allowing the kernel_t access to invisible devtmpfs floating somewhere, still
that is not
a SELinux policy bug.
Googling the discussion of kernel maintainers with devtmpfs authors made me
believe, that authors
intended devtmpfs for reduced userspace (embedded?) systems with no complex
interoperability
issues in mind.
Please do not turn CONFIG_DEVTMPFS=y in default debian kernels, that code is
not appropriately
designed and tested for everyone's use, moreover it is not required for debian
environment
to boot properly, debian have initramfs and udev.
At least until it is fixed to work in real world.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-3-686-bigmem (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
