From: russell@coker.com.au (Russell Coker)
Date: Wed, 28 Mar 2012 10:51:57 +1100
Subject: [refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?
In-Reply-To: <1d3c1e37-c258-47c6-8f6c-fda28ec65f71@email.android.com>
References: <20120327192447.GA2101@siphos.be>
	<1d3c1e37-c258-47c6-8f6c-fda28ec65f71@email.android.com>
Message-ID: <65fee91c-9c87-472b-ad30-a8ba9486c276@email.android.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

We should probably make "vipw -s" spawn a program named vipw-s (or something similar) so we can have different contexts for editing etc_t and shadow_t.

Russell Coker <russell@coker.com.au> wrote:

>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.

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