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
On Thursday 25 September 2008 07:38, Mike Edenfield <[email protected]> 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
Russell Coker wrote:
> On Thursday 25 September 2008 07:38, Mike Edenfield <[email protected]> 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.
On Friday 26 September 2008 06:11, Daniel J Walsh <[email protected]> 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Russell Coker wrote:
> On Friday 26 September 2008 06:11, Daniel J Walsh <[email protected]> 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-----
On Friday 26 September 2008 22:45, Daniel J Walsh <[email protected]> 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