login on embedded systems about refpolicy HOT 4 CLOSED

Hello, While working on supporting the refpolicy on embedded systems generated using Buildroot, I stumbled upon a login issue where the login system gets blocked from accessing the shadow_t context. I'm using a serial connexion handled by agetty and the util-linux login program. The following logs are output when asked for a password : buildroot login: root kauditd_printk_skb: 2 callbacks suppressed audit: type=1400 audit(1611839506.969:51): avc: denied { noatsecure } for pid=76 comm="agetty" scontext=system_u:system_r:getty_t tcontext=system_u:system_r:local_login_t tclass=process permissive=0 audit: type=1400 audit(1611839506.969:51): avc: denied { rlimitinh } for pid=76 comm="login" scontext=system_u:system_r:getty_t tcontext=system_u:system_r:local_login_t tclass=process permissive=0 audit: type=1400 audit(1611839506.969:51): avc: denied { siginh } for pid=76 comm="login" scontext=system_u:system_r:getty_t tcontext=system_u:system_r:local_login_t tclass=process permissive=0 audit: type=1400 audit(1611839507.069:52): avc: denied { read } for pid=76 comm="login" name="shadow" dev="vda" ino=88 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:shadow_t tclass=file permissive=0 Password: Then, no matter the password entered, the login fails. One thing to note is that these logs are only output when building with "make enableaudit", so the messages are hidden by a noaudit rule by default. Since this issue concerns the login process and accessing the shadow file, I'd rather get your opinion on that before trying to come-up with a patch. Adding "auth_read_shadow(local_login_t)" to the policy allows to login, but this doesn't look like this is the right solution. I'd therefore like have your inputs in that particular issue,

Maxime Chevallier ***@***.***> writes: > Hello, > > While working on supporting the refpolicy on embedded systems generated using Buildroot, I stumbled > upon a login issue where the login system gets blocked from accessing the shadow_t context. > > I'm using a serial connexion handled by agetty and the util-linux login program. > > The following logs are output when asked for a password : > > buildroot login: root > kauditd_printk_skb: 2 callbacks suppressed > audit: type=1400 audit(1611839506.969:51): avc: denied { noatsecure } for pid=76 comm="agetty" > scontext=system_u:system_r:getty_t tcontext=system_u:system_r:local_login_t tclass=process > permissive=0 > audit: type=1400 audit(1611839506.969:51): avc: denied { rlimitinh } for pid=76 comm="login" > scontext=system_u:system_r:getty_t tcontext=system_u:system_r:local_login_t tclass=process > permissive=0 > audit: type=1400 audit(1611839506.969:51): avc: denied { siginh } for pid=76 comm="login" > scontext=system_u:system_r:getty_t tcontext=system_u:system_r:local_login_t tclass=process > permissive=0 > audit: type=1400 audit(1611839507.069:52): avc: denied { read } for pid=76 comm="login" name="shadow" > dev="vda" ino=88 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:shadow_t > tclass=file permissive=0 > Password: > > Then, no matter the password entered, the login fails. > > One thing to note is that these logs are only output when building with "make enableaudit", so the > messages are hidden by a noaudit rule by default. > > Since this issue concerns the login process and accessing the shadow file, I'd rather get your opinion > on that before trying to come-up with a patch. > > Adding "auth_read_shadow(local_login_t)" to the policy allows to login, but this doesn't look like > this is the right solution. > > I'd therefore like have your inputs in that particular issue, We should make the above conditional with a tunable I guess, yes. I am a bit fuzzy on the details but the gist is that refpolicy policy is geared towards systems using PAM for authentication. There is some code in PAM that falls back to using unix_chkpwd when /etc/shadow is inaccesssible. This was done on purpose to limit access to /etc/shadow. Basically the idea was that pam clients wouldht have access to /etc/shadow, and that chkpwd would address that part automatigally, when pam clients were blocked access to /etc/shadow. The end result is that only the "trusted" chkpwd_t domain would need shadow access and not all individual pam client (reduce points of failures) If you dont have that PAM code though then yes you need this access, and so it should be supported. I suggest we add a well-documented built-time tunable that will allow pam clients to read shadow passwords conditionally something like: authlogin_pam_client_read_shadow with something similar to the above as the description.