Mailing List Archive: Some Selinux questions on a fresh install

Some Selinux questions on a fresh install

Feb 21, 2013, 12:46 PM

Post #1 of 7 (3851 views)

Hello everyone

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.

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. 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
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
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
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
avc: denied { getattr } for pid=411 comm="mkswap" name="/" dev="selinuxfs"
ino=1 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:security_t
tclass=filesystem
avc: denied { getattr } for pid=20 comm="kdevtmpfs" path="/dm-2"
dev="devtmpfs" ino=6891 scontext=system_u:system_r:kernel_t
tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file
avc: denied { read } for pid=1019 comm="syslog-ng" path="/dev/console"
dev="devtmpfs" ino=1039 scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:console_device_t tclass=chr_file
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. There's a few more errors
sometimes:

avc: denied { setattr } for pid=20 comm="kdevtmpfs" name="dm-2"
dev="devtmpfs" ino=1973 scontext=system_u:system_r:kernel_t
tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file
avc: denied { unlink } for pid=20 comm="kdevtmpfs" name="dm-2"
dev="devtmpfs" ino=1973 scontext=system_u:system_r:kernel_t
tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file
avc: denied { module_request } for pid=977 comm="sshd" kmod="net-pf-10"
scontext=system_u:system_r:sshd_t tcontext=system_u:system_r:kernel_t
tclass=system
avc: denied { use } for pid=977 comm="sshd" path="/dev/console"
dev="devtmpfs" ino=1039 scontext=system_u:system_r:sshd_t
tcontext=system_u:system_r:init_t tclass=fd
avc: denied { use } for pid=991 comm="cron" path="/dev/console"
dev="devtmpfs" ino=1039 scontext=system_u:system_r:crond_t
tcontext=system_u:system_r:init_t tclass=fd
avc: denied { read } for pid=127 comm="rc" name="openrc" dev="dm-0"
ino=591026 scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:file_t tclass=lnk_file
avc: denied { read } for pid=354 comm="hwclock" path="/dev/console"
dev="devtmpfs" ino=1039 scontext=system_u:system_r:hwclock_t
tcontext=system_u:object_r:console_device_t tclass=chr_file
avc: denied { search } for pid=1396 comm="X" name="1395" dev="proc"
ino=3997 scontext=user_u:user_r:xserver_t tcontext=user_u:user_r:user_t
tclass=dir
avc: denied { read } for pid=1396 comm="X" name="cmdline" dev="proc"
ino=3998 scontext=user_u:user_r:xserver_t tcontext=user_u:user_r:user_t
tclass=file
avc: denied { open } for pid=1396 comm="X" path="/proc/1395/cmdline"
dev="proc" ino=3998 scontext=user_u:user_r:xserver_t
tcontext=user_u:user_r:user_t tclass=file

Thoughts?
Thanks

BennyP

Re: Some Selinux questions on a fresh install [ In reply to ]

swift at gentoo

Feb 22, 2013, 11:27 AM

Post #2 of 7 (3739 views)

Permalink

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

Re: Some Selinux questions on a fresh install [ In reply to ]

ben at bennyp

Feb 23, 2013, 2:59 PM

Post #3 of 7 (3746 views)

Permalink

Nice to hear from you. I've gotten a bit of time today to search for some of
the causes, with the help of your tips:

>
> > 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.

It looks like this is because I am using a btrfs subvolume for root, and other
subvolumes for var, home, etc. Since the other subvolumes more or less exist
'above' root, they don't get labled correctly, so I have to do them manually.
Thanks for the heads up - I din't know file_t shouldn't exist.

> > 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.

A hard drive tuning parameter. From the source, cryptsetup looks to keep the
parameter the same for the dm device and the underlying device. Probably
should be allowed, but I'll try to verify.

> > 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 took a stab at this one. From the source, the program does two things that
possibly cause these:

1.) It checks if it is currently running under a tty (it calls isatty())
2.) Plays with the file contexts a bit. It tries to keep the correct file
contexts correct on /etc/passwd and /etc/shadow (I think). So it has to read
the correct contexts from selinux? (calls setfscreatecon() and
getfscreatecon() )

It's hard for me to debug though. Some denials are getting eaten somewhere and
don't show up in my logs (ie in passive mode, if I allow all the denials I see
and then rerun, I get different ones). This is true even after 'semodule -DB'

Still lots to learn I guess

Ben P.

Re: Some Selinux questions on a fresh install [ In reply to ]

aranea at aixah

Feb 24, 2013, 7:30 AM

Post #4 of 7 (3733 views)

Permalink

On Fri, 22 Feb 2013 19:27:00 +0000
Sven Vermeulen <swift@gentoo.org> wrote:

> 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) :-/

That's caused by a new grsecurity feature in hardened-sources-3.7.5,
I filed a bug about that a week ago:
https://bugs.gentoo.org/show_bug.cgi?id=457812

Regards,
Luis

Re: Some Selinux questions on a fresh install [ In reply to ]

swift at gentoo

Feb 24, 2013, 11:44 AM

Post #5 of 7 (3726 views)

Permalink

On Sun, Feb 24, 2013 at 04:30:28PM +0100, Luis Ressel wrote:
> > 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) :-/
>
> That's caused by a new grsecurity feature in hardened-sources-3.7.5,
> I filed a bug about that a week ago:
> https://bugs.gentoo.org/show_bug.cgi?id=457812

You saved me (probably) a couple of hours of brain-pain ;)

Wkr,
Sven Vermeulen

Re: Some Selinux questions on a fresh install [ In reply to ]

swift at gentoo

Feb 24, 2013, 11:49 AM

Post #6 of 7 (3728 views)

Permalink

On Sat, Feb 23, 2013 at 05:59:28PM -0500, Ben P. wrote:
> > > 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
>
> 2.) Plays with the file contexts a bit. It tries to keep the correct file
> contexts correct on /etc/passwd and /etc/shadow (I think). So it has to read
> the correct contexts from selinux? (calls setfscreatecon() and
> getfscreatecon() )

Makes sense; if unix_chkpwd is SELinux-aware, it probably wants to read some
files in the SELinux file system, which is under /sys (thus the search
privileges on sysfs_t directories).

The filesystem one however (getattr on security_t filesystem) is not clear
to me (I find the "filesystem" class difficult to grasp). I *think* that
getattr on filesystem classes is something like getting the mount options of
a file system?

Alas, http://www.selinuxproject.org/page/ObjectClassesPerms#filesystem isn't
clear on this :-(

> Still lots to learn I guess

Same here :-/

Wkr,
Sven Vermeulen

Re: Some Selinux questions on a fresh install [ In reply to ]

ben at bennyp

Mar 1, 2013, 11:47 AM

Post #7 of 7 (3731 views)

Permalink

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.

Mailing List Archive

Mailing List Archive

Attached Files: