From mboxrd@z Thu Jan  1 00:00:00 1970
From: russell@coker.com.au (Russell Coker)
Date: Wed, 28 Mar 2012 10:47:24 +1100
Subject: [refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?
In-Reply-To: <20120327192447.GA2101@siphos.be>
References: <20120327192447.GA2101@siphos.be>
Message-ID: <1d3c1e37-c258-47c6-8f6c-fda28ec65f71@email.android.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

The vipw program runs in a domain that has a default type for files created under /etc of shadow_t, it has to be this way to avoid allowing inappropriate read access to /etc/shadow data.

It is not desirable to have chsh get read access to shadow_t.  Maybe we should have special code in vipw etc to label the lock file as etc_t.  I don't think we need a special type for such lock files.

Sven Vermeulen <sven.vermeulen@siphos.be> wrote:

>In Gentoo, we notice that recent shadow package (version 4.1.5) has a
>change
>in behavior for changing account information through chsh. Although the
>application only edits /etc/passwd entries, it now uses the
>/etc/.pwd.lock
>file to prevent concurrent changes to the /etc/passwd (and other
>account-related files). 
>
>In the current policy however, /etc/.pwd.lock is marked as shadow_t, so
>the
>chsh application (running in chfn_t) does not have the proper
>privileges to
>work on this. As a result, it fails to update /etc/passwd entries.
>
>As I'm not going to give it read/write access to shadow_t files, one
>other
>possibility would be to mark /etc/.pwd.lock as etc_t. But I can imagine
>that
>it was given shadow_t on purpose previously, probably to prevent a
>malicious
>program (that has write access to etc_t) to update the lock file so
>concurrent write operations on /etc/shadow could result in
>corruption...
>
>Another solution would be to patch chsh itself to use a different lock
>file,
>but unless it's accepted upstream, it's only a "local" remedy.
>
>A third solution would be to create and use a different type for it,
>like
>etc_auth_lock_t or whatever imagination can bring to life, and update
>the
>policies of all domains that need access to it towards it.
>
>Any thoughts on this?
>
>Wkr,
>	Sven Vermeulen
>
>_______________________________________________
>refpolicy mailing list
>refpolicy at oss.tresys.com
>http://oss.tresys.com/mailman/listinfo/refpolicy

-- 
Sent from my Samsung Galaxy S Android phone with K-9 Mail.