[refpolicy] useradd/passwd patch

[refpolicy] useradd/passwd patch

[Mike Edenfield]

Allows passwd and useradd to execute unix_chkpwd (and related binaries) 
to read and update user passwords.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: refpolicy-chk_passwd.diff
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20080924/1c0f09d8/attachment.pl 

[refpolicy] useradd/passwd patch

[Russell Coker]

On Thursday 25 September 2008 07:38, Mike Edenfield <kutulu@kutulu.org> wrote:
> Allows passwd and useradd to execute unix_chkpwd (and related binaries)
> to read and update user passwords.

Why would passwd and useradd ever need to do that?

unix_chkpwd is only ever called if the shadow file can't be read directly.  
passwd needs direct read access and while it might be possible to write a 
useradd that doesn't need read access (if based on the assumption 
that /etc/shadow would never be in any way corrupt or out of sync 
with /etc/paasswd), realistically it will always need such access.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

[refpolicy] useradd/passwd patch

[Daniel J Walsh]

Russell Coker wrote:
> On Thursday 25 September 2008 07:38, Mike Edenfield <kutulu@kutulu.org> wrote:
>> Allows passwd and useradd to execute unix_chkpwd (and related binaries)
>> to read and update user passwords.
> 
> Why would passwd and useradd ever need to do that?
> 
> unix_chkpwd is only ever called if the shadow file can't be read directly.  
> passwd needs direct read access and while it might be possible to write a 
> useradd that doesn't need read access (if based on the assumption 
> that /etc/shadow would never be in any way corrupt or out of sync 
> with /etc/paasswd), realistically it will always need such access.
> 
Perhaps they are using pam to verify password entry, pam defaults to
unix_chkpwd so this could cause the avc.  I don't see where this is a
problem though.

[refpolicy] useradd/passwd patch

[Russell Coker]

On Friday 26 September 2008 06:11, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Perhaps they are using pam to verify password entry, pam defaults to
> unix_chkpwd so this could cause the avc. ?I don't see where this is a
> problem though.

Since when does PAM default to unix_chkpwd?

When I first wrote the code and policy for this PAM had special-case code to 
only call unix_chkpwd in the case of a non-root caller.

It might make some sense to only check the password in one way (IE call the 
executable even when running as root without SE Linux) as it's not something 
that happens often enough to cause performance.  But in that case I think 
that the suitably privileged domains should be permitted to execute 
unix_chkpwd in the same domain.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

[refpolicy] useradd/passwd patch

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russell Coker wrote:
> On Friday 26 September 2008 06:11, Daniel J Walsh <dwalsh@redhat.com> wrote:
>> Perhaps they are using pam to verify password entry, pam defaults to
>> unix_chkpwd so this could cause the avc.  I don't see where this is a
>> problem though.
> 
> Since when does PAM default to unix_chkpwd?
> 
> When I first wrote the code and policy for this PAM had special-case code to 
> only call unix_chkpwd in the case of a non-root caller.
> 
And I believe that has changed.  Since were having to dontaudit read of
shadow for all pam apps, while if they try to use unix_chppwd first we
don't need the dontaudit rule.  Then if a domain suddenly tries to read
shadow, we have an idea that there is some problem.
> It might make some sense to only check the password in one way (IE call the 
> executable even when running as root without SE Linux) as it's not something 
> that happens often enough to cause performance.  But in that case I think 
> that the suitably privileged domains should be permitted to execute 
> unix_chkpwd in the same domain.
> 
And how is this more or less secure?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjc2VUACgkQrlYvE4MpobOICwCdFHv5JZNwdc+qIwzywSl9YZWV
1zcAoJo/2HLijdsQyGt5iYKBmsp5XT8W
=bJWN
-----END PGP SIGNATURE-----

[refpolicy] useradd/passwd patch

[Russell Coker]

On Friday 26 September 2008 22:45, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > It might make some sense to only check the password in one way (IE call
> > the executable even when running as root without SE Linux) as it's not
> > something that happens often enough to cause performance.  But in that
> > case I think that the suitably privileged domains should be permitted to
> > execute unix_chkpwd in the same domain.
>
> And how is this more or less secure?

Having only one code path to audit can only be a win for security.

If a domain is permitted to write to shadow_t then having unix_chkpwd executed 
in the same domain doesn't make any difference to security but will reduce 
the size of the policy a little.

-- 
russell at coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development