[refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?

[refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?

[Sven Vermeulen]

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] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/27/2012 03:24 PM, 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
Being able to write to etc_t is basically the same as being able to write to shadow_t, if /etc/passwd is labeled as etc_t.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9yI6MACgkQrlYvE4MpobPOegCg6i+NN+phGriaJl5W4/5N9xB5
16EAn27LFy9tO/aO+UEw5HXIjjrmqNHX
=oEnZ
-----END PGP SIGNATURE-----

[refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?

[Sven Vermeulen]

On Tue, Mar 27, 2012 at 04:31:31PM -0400, Daniel J Walsh wrote:
> Being able to write to etc_t is basically the same as being able to write to shadow_t, if /etc/passwd is labeled as etc_t.

How's that? The passwd file is labeled as etc_t, shadow is labeled as
shadow_t. And apparently, .pwd.lock is labeled as shadow_t as well
currently.

I'm pretty sure domains with write privileges to etc_t cannot write to
shadow_t...

Wkr,
	Sven Vermeulen

[refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/28/2012 12:52 PM, Sven Vermeulen wrote:
> On Tue, Mar 27, 2012 at 04:31:31PM -0400, Daniel J Walsh wrote:
>> Being able to write to etc_t is basically the same as being able to write to shadow_t, if /etc/passwd is labeled as etc_t.
> 
> How's that? The passwd file is labeled as etc_t, shadow is labeled as shadow_t. And apparently, .pwd.lock is labeled as shadow_t as well currently.
> 
> I'm pretty sure domains with write privileges to etc_t cannot write to shadow_t...
> 
> Wkr, Sven Vermeulen _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
Because I can write a /etc/passwd file entry to allow me to login to root without a password,
and then just use a login program to login as root, probably running as a role of sysadmin_t
or uncnfined_t

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9zR0wACgkQrlYvE4MpobNJ3ACeJ+dum4qGuDDAmig5w21hJevf
UhUAoLQGl56J/jN1LAhP/SFlXzVssLIA
=Y7vB
-----END PGP SIGNATURE-----

[refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?

[Russell Coker]

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.

[refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?

[Russell Coker]

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.

[refpolicy] chsh (chfn_t) to access /etc/.pwd.lock (shadow_t) ?

[Sven Vermeulen]

On Wed, Mar 28, 2012 at 10:51:57AM +1100, Russell Coker wrote:
> 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.

It might be easier just to use a named file transition here...

Wkr,
	Sven Vermeulen