New file getting different context than what restorecond specifies

[Dominick Grift]

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

On 01/31/2011 04:34 PM, Luis Fernando Muñoz Mejías wrote:
> Hello, list.
> 
> I'm having quite some difficulties in understanding some SELinux
> behaviour, and Google is not helping...
> 
> On an RHEL6-based system using the targeted policy, when we create our
> .k5login files, they get the context of their parent directory, and
> *not* the one specified in the policy for .k5login. Calling restorecon
> gives them the correct context, but I would expect it to be correct
> since the file is created.
> 
> The file_contexts file looks like this:
> 
> 19:/root(/.*)?  system_u:object_r:admin_home_t:s0
> 2353:/root/\.k5login    --      system_u:object_r:krb5_home_t:s0
> 
> And the behaviour we get is:
> 
> ************************************************************
> # Initial status:
> ~ # sestatus
> SELinux status:                 enabled
> SELinuxfs mount:                /selinux
> Current mode:                   enforcing
> Mode from config file:          permissive
> Policy version:                 24
> Policy from config file:        targeted
> ~ # LANG=C ls -a .k5login
> ls: cannot access .k5login: No such file or directory
> 
> # Create the file
> ~ # echo foo at CERN.CH > .k5login
> ~ # ls -Z .k5login
> -rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 .k5login
> 
> # But restorecon gives it the correct context!!
> ~ # restorecon .k5login
> ~ # ls -Z .k5login
> -rw-r--r--. root root system_u:object_r:krb5_home_t:s0 .k5login
> ************************************************************
> 
> I would expect that newly-created files wouldn't need a restorecon,
> unless the policy changed or they were created when SELinux was
> disabled. Am I wrong? Or is it a bug in the policy?
> 
> Thanks a lot.
> 
> 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?

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.

These rules are basically defined like this:

when a process with a specific domain_type creates a (for example) file
in a directory with a specified file_type, then type_transition from the
specified directory file_type to a the specified file file_type.

Such a rule would look like this:

allow some_process_t some_file_t:file manage_file_perms;
type_transition some_process_t some_directory_t:file some_file_t;

The problem in your case is that it seems no such rule is defined,
and that whatever process creates the file runs with the user process
domain_type

I think i know why this rules is not defined.

I suspect that is because that file is created by the user process
domain_type.

If we would specify a type_transition rule for it, then that would
basically mean that all files created by the user, below the $home
directory (user_home_dir_t) would be created with this specified file
type ( in your case krb5_home_t ). This is obviously also not a good idea.

And so we would have to make some decisions here:

(1) Either you run restorecon on the file so that it gets reset manually
from user_home_t to krb5_home_t, (2) or you allow whatever currently
breaks this, to read files with type user_home_t. That way you do not
have to worry about having to reset ~/.k5login files manually with
restorecon.

(3) One other possible option would be to confine whatever program the
user runs to create this file, and then specify a type_transition for
this confined programs domain_type. However i suspect that this may not
be so easy.

1. What program that is executed by users creates this ~/.k5login file
(if any)

2. Which process is denied access to read mislabeled ~/.k5login files,
and is causing your set up to break? Can you enclose avc denials of this
event?

> 
> PPS: I'm using: selinux-policy-targeted-3.7.19-54.el6.noarch

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

iEYEARECAAYFAk1G4fUACgkQMlxVo39jgT9zrQCeMAEAV3wj4AgM06jhiMBqOddP
g8IAn3mVYl9aGCIzoTdfnMaX3UtfQGuM
=nkjG
-----END PGP SIGNATURE-----