On Tuesday 05 August 2008 22:48:55 Stephen Smalley wrote:
> On Tue, 2008-08-05 at 22:32 +0800, Dennis Wronka wrote:
> > Thanks.
> > That seems to help quite a bit.
> > I now get some messages. For example it seems that newrole wants to
> > read /etc/shadow directly.
> > Will check those messages and play around with the policy.
>
> The way it works is that pam_unix attempts to open /etc/shadow directly
> for reading, and if it fails, it falls back to running unix_chkpwd to
> perform the password check. SELinux policy prohibits most programs from
> directly reading /etc/shadow, including even ones that run as root, and
> forces them to go through unix_chkpwd instead, in order to limit the set
> of processes that have full read access to the shadow password file.
>
> The logic to try to open /etc/shadow and fall back to unix_chkpwd
> already existed before SELinux in order to support non-root processes
> re-authenticating the current user. What changed with SELinux was that
> it could also happen for root processes.
>
> The current policy dontaudit's the attempt to directly read /etc/shadow
> to avoid noise. When you did semodule -DB, you turned on that auditing.
> But those denials are what is expected, and allowing them will mean
> giving newrole direct read access to /etc/shadow (although that will
> only work if running as root, of course, as otherwise it has to use a
> suid helper like unix_chkpwd anyway).
>
> Does newrole work for you as a non-root user?
Okay, it looks like that unix_chkpwd is not allowed to read /etc/shadow when
running in newrole_t.
Here's the message:
type=1400 audit(1217920543.235:26): avc: denied { read } for pid=1210
comm="unix_chkpwd" name="shadow" dev=dm-0 ino=29366926
scontext=staff_u:staff_r:newrole_t tcontext=system_u:object_r:shadow_t
tclass=file
Is it safe to add the rule suggested by audit2allow "allow newrole_t
shadow_t:file read;" to the policy or would there be a better way?
Wouldn't it in general be better if unix_chkpwd would transition into a domain
for itself which then in turn is allowed to access /etc/shadow?
Attachment:
signature.asc
Description: This is a digitally signed message part.
