Re: [gentoo-hardened] Some Selinux questions on a fresh install

[Ben P.]

On Friday, February 22, 2013 07:27:00 PM Sven Vermeulen wrote:
> 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
> >


I solved the problem with denials not being printed, and found a few other 
problems with the selinux policies.

Rather than spam the mailing list, I've put them up at 
http://www.bennyp.org/selinux/ . (Don't worry, no ads or anything there). In 
particular:

* Samba wouldn't start
* Couldn't mount anything on /var/tmp/portage
* The cryptsetup thing
* Udev/initrc misbehaving

If you want, I can certainly add some of these to the bugtracker so you can 
officially record them. Keep in mind though that I've been looking at selinux 
for a total of about 2 weeks :)

Also, if anyone is interested in testing out some (likely buggy and full of 
holes) modules, I've written a module for tightvnc (see the site). This allows 
a user to start a remote XVnc session accessible through ssh. It's probably 
not a topic for this mailing list, however.

After much of the changes documented on that site, my system is running pretty 
smoothly in enforcing mode :)

Keep up the good work
Ben P.