| 1 |
On Thu, Feb 21, 2013 at 03:46:14PM -0500, Ben P. wrote: |
| 2 |
> I've put Gentoo-Hardened on a testing computer and been learning a lot about |
| 3 |
> selinux. Everything works, including X, but I have a few entries in my avc log |
| 4 |
> that I'm not sure about. |
| 5 |
|
| 6 |
Cool, let's take a look. But generally, if you have denials but no problems, |
| 7 |
you might want to dontaudit them if they are in your way. To make sure there |
| 8 |
is no difference in behavior, you can try booting in permissive mode once |
| 9 |
and compare with running in enforcing mode just to be sure. |
| 10 |
|
| 11 |
That being said, some denials might give us a few clues as to what might |
| 12 |
still be needed. |
| 13 |
|
| 14 |
> I note that this is running on an encrypted root drive and therefore I need an |
| 15 |
> initramfs. Dracut wasn't working for me so I rolled my own, which does boot in |
| 16 |
> enforcing mode (with a few minor errors) so bug 397567 seems to not be |
| 17 |
> universal. |
| 18 |
|
| 19 |
Yes, I think the needed changes have been made to kernel_t already to allow |
| 20 |
"standard" bootups to succeed. However, due to the complexity that an |
| 21 |
initramfs can inhibit (say you use an initramfs to NFS-mount file systems, |
| 22 |
load up a trusted key through the TPM chip and what not) it's pretty obvious |
| 23 |
that kernel_t will not always be equally sufficient. |
| 24 |
|
| 25 |
> So some of these errors may be due to the initramfs then, although |
| 26 |
> I'm not sure why, since almost everything is unmounted before switch_root. |
| 27 |
> |
| 28 |
> avc: denied { read write } for pid=1 comm="init" |
| 29 |
> path=2F6465762F636F6E736F6C65202864656C6574656429 dev="rootfs" ino=5998 |
| 30 |
> scontext=system_u:system_r:init_t tcontext=system_u:object_r:root_t |
| 31 |
> tclass=chr_file |
| 32 |
|
| 33 |
No idea what it is trying to do here, but given that it is about a path-less |
| 34 |
character file (which probably means that the path cannot be devised from |
| 35 |
the current location, either because the file has been removed or due to a |
| 36 |
chroot) and that the permissions are read/write (and not open), I'd guess |
| 37 |
this is an inherited file descriptor towards that character device and most |
| 38 |
likely a leaked, inherited fd. Thus might be ok to not allow (and perhaps |
| 39 |
even dontaudit). |
| 40 |
|
| 41 |
> avc: denied { getattr } for pid=1 comm="init" name="/" dev="selinuxfs" |
| 42 |
> ino=1 scontext=system_u:system_r:init_t tcontext=system_u:object_r:security_t |
| 43 |
> tclass=filesystem |
| 44 |
|
| 45 |
This is probably ok to allow, but not strictly necessary afaik. |
| 46 |
|
| 47 |
|
| 48 |
> avc: denied { search } for pid=1 comm="init" name="var" dev="dm-0" |
| 49 |
> ino=556492 scontext=system_u:system_r:init_t tcontext=system_u:object_r:file_t |
| 50 |
> tclass=dir |
| 51 |
|
| 52 |
This is somewhat more wrong. file_t is a type that shouldn't be on the file |
| 53 |
system after it has been fully labeled. |
| 54 |
|
| 55 |
> avc: denied { write } for pid=400 comm="cryptsetup" name="read_ahead_kb" |
| 56 |
> dev="sysfs" ino=14972 scontext=system_u:system_r:lvm_t |
| 57 |
> tcontext=system_u:object_r:sysfs_t tclass=file |
| 58 |
|
| 59 |
Probably ok to allow - I don't know much about the optimizations that are |
| 60 |
possible, but it seems that cryptsetup here is trying to optimize for |
| 61 |
something. You might not even notice that since it often is for specific |
| 62 |
corner cases. |
| 63 |
|
| 64 |
> avc: denied { read write } for pid=1084 comm="unix_chkpwd" path="/dev/tty1" |
| 65 |
> dev="devtmpfs" ino=1045 scontext=system_u:system_r:chkpwd_t |
| 66 |
> tcontext=system_u:object_r:tty_device_t tclass=chr_file |
| 67 |
> avc: denied { search } for pid=1084 comm="unix_chkpwd" name="/" dev="sysfs" |
| 68 |
> ino=1 scontext=system_u:system_r:chkpwd_t tcontext=system_u:object_r:sysfs_t |
| 69 |
> tclass=dir |
| 70 |
> avc: denied { getattr } for pid=1084 comm="unix_chkpwd" name="/" |
| 71 |
> dev="selinuxfs" ino=1 scontext=system_u:system_r:chkpwd_t |
| 72 |
> tcontext=system_u:object_r:security_t tclass=filesystem |
| 73 |
> avc: denied { getattr } for pid=1084 comm="unix_chkpwd" |
| 74 |
> path="/sys/fs/selinux" dev="selinuxfs" ino=1 |
| 75 |
> scontext=system_u:system_r:chkpwd_t tcontext=system_u:object_r:security_t |
| 76 |
> tclass=dir |
| 77 |
> |
| 78 |
> Particularly, I get a lot of unix_chkpwd denials. |
| 79 |
|
| 80 |
Yes, I have unix_chkpwd denials here everywhere as well. Don't know why |
| 81 |
though, and haven't noticed anything unusual. I was planning on checking the |
| 82 |
source code when I have more time to see why it wants to do all these |
| 83 |
things. The denials I have are not fully the same as yours though. |
| 84 |
|
| 85 |
I also notice a lot of capability (mknod) requests in the denials - again, |
| 86 |
without noticeable change in behavior. Very awkward to debug - I can't just |
| 87 |
dontaudit it (not convinced they aren't needed) nor allow (not convinced |
| 88 |
they are needed) :-/ |
| 89 |
|
| 90 |
Wkr, |
| 91 |
Sven Vermeulen |
Archives