New file getting different context than what restorecond specifies

[Dominick Grift]

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

On 01/31/2011 06:19 PM, Luis Fernando Muñoz Mejías wrote:
> Dominick,
> 
> That was a fast reply. Thanks. :)
> 
>>> PS: I suppose this problem applies to other files, we've been hit with
>>> .k5login first (users couldn't SSH in).
>>
>> What AVC were you seeing when this event occurred?
> 
> type=AVC msg=audit(1296482283.843:119943): avc: denied { read } for
> pid=30058 comm="sshd" name=".k5login" dev=sda2 ino=362102
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
> 
> type=AVC msg=audit(1296482283.843:119943): avc: denied { open } for
> pid=30058 comm="sshd" name=".k5login" dev=sda2 ino=362102
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
> 
> type=AVC msg=audit(1296482283.843:119944): avc: denied { getattr } for
> pid=30058 comm="sshd" path="/root/.k5login" dev=sda2 ino=362102
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
> 
>> This indeed seems to be a non optimal solution/situation.
>>
>> The file ~/.k5login is specified to have a specific context
>> (krb5_home_t). But the file indeed seems to not get created with this
>> specified context (because nothing specifies that this should happen).
>>
>> Usually the creation of objects with types that are not the same as the
>> type of the parent directory are specified using a type_transition rule.
>>
> You mean this rule:
> 
> type_transition unconfined_t admin_home_t:file krb5_home_t;
> 
> But, as you pointed out, this means that specify that all files created
> by unconfined_t in admin_home_t have krb5_home_t context. Not good.
> 
> What I expect from reading a policy is this: if a process context is
> allowed to create in a directory, new files should have the context the
> policy specifies, so that SELinux-unaware code (f.i, automatic config
> generators) doesn't break.

And in this case it does. The policy basically specifies that when
unconfined_t creates a file in a admin_home_t directories, that this
file inherits the type of the parent directory.

The issue in this case is that no type_transition was define because
that would cause all files created by unconfined_t below admin_home_t
directories to be created with the krb5_home_t type.

> Assigning a context that differs from the default should be a
> SELinux-protected operation, IMHO.
> 

I am not sure what you mean here but as far as i am concerned it is a
selinux protected operation.

>> (1) Either you run restorecon on the file so that it gets reset manually
>> from user_home_t to krb5_home_t,
> 
> This is what I'll have to do. :(
> 
>> 1. What program that is executed by users creates this ~/.k5login file
>> (if any)
>>
> It's our configuration management system. Essentially, it's a Perl
> module that unlinks the old file (to prevent symlink attacks, the code
> runs as root and enters in untrusted directories), creates the new one
> with O_CREAT|O_EXCL flags and prints to it, according to some
> description that comes from the golden server.
> 
> I can't confine it into a different policy because the system is
> plugin-based, and doesn't fork. I'd need to fork for each plugin and
> define a good SELinux context for each plugin, and that's way too
> complicated.

ok i guess you could just script it to run restorecon after it created
the file. Although i guess that causes a race situation.

This issue should in my view be revisited/reassessed regardless of your
specific issue.

It does not make sense to specify the context of a file to be one that
it doesnt get created with.

I hope others can comment on this.

> 
> Thanks again for your reply. It has improved quite a lot my
> understanding of SELinux.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1G8tEACgkQMlxVo39jgT8TuwCgrCqp93Qtc4VRCOckJ1j4l/cl
j/kAoJ2e+DcW01Rd9e9zKxiBcc6bGedG
=oaRK
-----END PGP SIGNATURE-----