| 1 |
Nice to hear from you. I've gotten a bit of time today to search for some of |
| 2 |
the causes, with the help of your tips: |
| 3 |
|
| 4 |
> |
| 5 |
> > avc: denied { search } for pid=1 comm="init" name="var" dev="dm-0" |
| 6 |
> > ino=556492 scontext=system_u:system_r:init_t |
| 7 |
> > tcontext=system_u:object_r:file_t tclass=dir |
| 8 |
> |
| 9 |
> This is somewhat more wrong. file_t is a type that shouldn't be on the file |
| 10 |
> system after it has been fully labeled. |
| 11 |
|
| 12 |
It looks like this is because I am using a btrfs subvolume for root, and other |
| 13 |
subvolumes for var, home, etc. Since the other subvolumes more or less exist |
| 14 |
'above' root, they don't get labled correctly, so I have to do them manually. |
| 15 |
Thanks for the heads up - I din't know file_t shouldn't exist. |
| 16 |
|
| 17 |
> > avc: denied { write } for pid=400 comm="cryptsetup" |
| 18 |
> > name="read_ahead_kb" |
| 19 |
> > dev="sysfs" ino=14972 scontext=system_u:system_r:lvm_t |
| 20 |
> > tcontext=system_u:object_r:sysfs_t tclass=file |
| 21 |
> |
| 22 |
> Probably ok to allow - I don't know much about the optimizations that are |
| 23 |
> possible, but it seems that cryptsetup here is trying to optimize for |
| 24 |
> something. You might not even notice that since it often is for specific |
| 25 |
> corner cases. |
| 26 |
|
| 27 |
A hard drive tuning parameter. From the source, cryptsetup looks to keep the |
| 28 |
parameter the same for the dm device and the underlying device. Probably |
| 29 |
should be allowed, but I'll try to verify. |
| 30 |
|
| 31 |
|
| 32 |
> > avc: denied { read write } for pid=1084 comm="unix_chkpwd" |
| 33 |
> > path="/dev/tty1" dev="devtmpfs" ino=1045 |
| 34 |
> > scontext=system_u:system_r:chkpwd_t |
| 35 |
> > tcontext=system_u:object_r:tty_device_t tclass=chr_file |
| 36 |
> > avc: denied { search } for pid=1084 comm="unix_chkpwd" name="/" |
| 37 |
> > dev="sysfs" ino=1 scontext=system_u:system_r:chkpwd_t |
| 38 |
> > tcontext=system_u:object_r:sysfs_t tclass=dir |
| 39 |
> > avc: denied { getattr } for pid=1084 comm="unix_chkpwd" name="/" |
| 40 |
> > dev="selinuxfs" ino=1 scontext=system_u:system_r:chkpwd_t |
| 41 |
> > tcontext=system_u:object_r:security_t tclass=filesystem |
| 42 |
> > avc: denied { getattr } for pid=1084 comm="unix_chkpwd" |
| 43 |
> > path="/sys/fs/selinux" dev="selinuxfs" ino=1 |
| 44 |
> > scontext=system_u:system_r:chkpwd_t tcontext=system_u:object_r:security_t |
| 45 |
> > tclass=dir |
| 46 |
> > |
| 47 |
> > Particularly, I get a lot of unix_chkpwd denials. |
| 48 |
> |
| 49 |
> Yes, I have unix_chkpwd denials here everywhere as well. Don't know why |
| 50 |
> though, and haven't noticed anything unusual. I was planning on checking the |
| 51 |
> source code when I have more time to see why it wants to do all these |
| 52 |
> things. The denials I have are not fully the same as yours though. |
| 53 |
|
| 54 |
I took a stab at this one. From the source, the program does two things that |
| 55 |
possibly cause these: |
| 56 |
|
| 57 |
1.) It checks if it is currently running under a tty (it calls isatty()) |
| 58 |
2.) Plays with the file contexts a bit. It tries to keep the correct file |
| 59 |
contexts correct on /etc/passwd and /etc/shadow (I think). So it has to read |
| 60 |
the correct contexts from selinux? (calls setfscreatecon() and |
| 61 |
getfscreatecon() ) |
| 62 |
|
| 63 |
It's hard for me to debug though. Some denials are getting eaten somewhere and |
| 64 |
don't show up in my logs (ie in passive mode, if I allow all the denials I see |
| 65 |
and then rerun, I get different ones). This is true even after 'semodule -DB' |
| 66 |
|
| 67 |
Still lots to learn I guess |
| 68 |
|
| 69 |
Ben P. |
Archives