Bug#579746: linux-image-2.6.32-3-686-bigmem: Permission denials in devtmpfs handlers DO break the rest of the kernel.
reassign 579746 refpolicy
thanks
On Fri, Apr 30, 2010 at 02:50:26PM +0400, spg wrote:
> 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.
devtmpfs will remain for Squeeze, if you want to see this fixed in Squeeze, it
should be covered in refpolicy.
Cheers,
Moritz
Reply to: