[refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?
Russell Coker
russell at coker.com.au
Tue Mar 27 18:51:57 CDT 2012
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 at 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 at 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.
More information about the refpolicy
mailing list