On Thu, Feb 21, 2013 at 03:46:14PM -0500, Ben P. wrote:
> I've put Gentoo-Hardened on a testing computer and been learning a lot about
> selinux. Everything works, including X, but I have a few entries in my avc
> log
> that I'm not sure about.
Cool, let's take a look. But generally, if you have denials but no problems,
you might want to dontaudit them if they are in your way. To make sure there
is no difference in behavior, you can try booting in permissive mode once
and compare with running in enforcing mode just to be sure.
That being said, some denials might give us a few clues as to what might
still be needed.
> I note that this is running on an encrypted root drive and therefore I need
> an
> initramfs. Dracut wasn't working for me so I rolled my own, which does boot
> in
> enforcing mode (with a few minor errors) so bug 397567 seems to not be
> universal.
Yes, I think the needed changes have been made to kernel_t already to allow
"standard" bootups to succeed. However, due to the complexity that an
initramfs can inhibit (say you use an initramfs to NFS-mount file systems,
load up a trusted key through the TPM chip and what not) it's pretty obvious
that kernel_t will not always be equally sufficient.
> So some of these errors may be due to the initramfs then, although
> I'm not sure why, since almost everything is unmounted before switch_root.
>
> avc: denied { read write } for pid=1 comm="init"
> path=2F6465762F636F6E736F6C65202864656C6574656429 dev="rootfs" ino=5998
> scontext=system_u:system_r:init_t tcontext=system_u:object_r:root_t
> tclass=chr_file
No idea what it is trying to do here, but given that it is about a path-less
character file (which probably means that the path cannot be devised from
the current location, either because the file has been removed or due to a
chroot) and that the permissions are read/write (and not open), I'd guess
this is an inherited file descriptor towards that character device and most
likely a leaked, inherited fd. Thus might be ok to not allow (and perhaps
even dontaudit).
> avc: denied { getattr } for pid=1 comm="init" name="/" dev="selinuxfs"
> ino=1 scontext=system_u:system_r:init_t tcontext=system_u:object_r:security_t
> tclass=filesystem
This is probably ok to allow, but not strictly necessary afaik.
> avc: denied { search } for pid=1 comm="init" name="var" dev="dm-0"
> ino=556492 scontext=system_u:system_r:init_t
> tcontext=system_u:object_r:file_t
> tclass=dir
This is somewhat more wrong. file_t is a type that shouldn't be on the file
system after it has been fully labeled.
> avc: denied { write } for pid=400 comm="cryptsetup" name="read_ahead_kb"
> dev="sysfs" ino=14972 scontext=system_u:system_r:lvm_t
> tcontext=system_u:object_r:sysfs_t tclass=file
Probably ok to allow - I don't know much about the optimizations that are
possible, but it seems that cryptsetup here is trying to optimize for
something. You might not even notice that since it often is for specific
corner cases.
> avc: denied { read write } for pid=1084 comm="unix_chkpwd"
> path="/dev/tty1"
> dev="devtmpfs" ino=1045 scontext=system_u:system_r:chkpwd_t
> tcontext=system_u:object_r:tty_device_t tclass=chr_file
> avc: denied { search } for pid=1084 comm="unix_chkpwd" name="/"
> dev="sysfs"
> ino=1 scontext=system_u:system_r:chkpwd_t tcontext=system_u:object_r:sysfs_t
> tclass=dir
> avc: denied { getattr } for pid=1084 comm="unix_chkpwd" name="/"
> dev="selinuxfs" ino=1 scontext=system_u:system_r:chkpwd_t
> tcontext=system_u:object_r:security_t tclass=filesystem
> avc: denied { getattr } for pid=1084 comm="unix_chkpwd"
> path="/sys/fs/selinux" dev="selinuxfs" ino=1
> scontext=system_u:system_r:chkpwd_t tcontext=system_u:object_r:security_t
> tclass=dir
>
> Particularly, I get a lot of unix_chkpwd denials.
Yes, I have unix_chkpwd denials here everywhere as well. Don't know why
though, and haven't noticed anything unusual. I was planning on checking the
source code when I have more time to see why it wants to do all these
things. The denials I have are not fully the same as yours though.
I also notice a lot of capability (mknod) requests in the denials - again,
without noticeable change in behavior. Very awkward to debug - I can't just
dontaudit it (not convinced they aren't needed) nor allow (not convinced
they are needed) :-/
Wkr,
Sven Vermeulen
