login on embedded systems

[minimaxwell]

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,

Thanks a lot,

Maxime

[ghost]

Maxime Chevallier <notifications@github.com> 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.

…

Thanks a lot, Maxime — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

-- gpg --locate-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift

[ghost]

Dominick Grift <dominick.grift@defensec.nl> writes:

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.

here is where that stuff happens: https://github.com/SELinuxProject/refpolicy/blob/master/policy/modules/system/authlogin.if#L43

…

> > Thanks a lot, > > Maxime > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or unsubscribe. >

-- gpg --locate-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift

[ghost]

... then again, especially on embedded systems, you probably might want to exclude the authlogin module altogether (amongst many other modules) the issue is that doing this will open up another can of worms.

[pebenito]

@minimaxwell please see if #364 will address your needs. I added an authlogin_pam tunable that is default to true, so existing users are not impacted. If you set it to false, it will add the shadow_t access.