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.
