All of lore.kernel.org
 help / color / mirror / Atom feed
From: russell@coker.com.au (Russell Coker)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?
Date: Wed, 28 Mar 2012 10:47:24 +1100	[thread overview]
Message-ID: <1d3c1e37-c258-47c6-8f6c-fda28ec65f71@email.android.com> (raw)
In-Reply-To: <20120327192447.GA2101@siphos.be>

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.

  parent reply	other threads:[~2012-03-27 23:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-27 19:24 [refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ? Sven Vermeulen
2012-03-27 20:31 ` Daniel J Walsh
2012-03-28 16:52   ` Sven Vermeulen
2012-03-28 17:15     ` Daniel J Walsh
2012-03-27 23:47 ` Russell Coker [this message]
2012-03-27 23:51   ` Russell Coker
2012-03-28 16:53     ` Sven Vermeulen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1d3c1e37-c258-47c6-8f6c-fda28ec65f71@email.android.com \
    --to=russell@coker.com.au \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.