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