New file getting different context than what restorecond specifies

[Dominick Grift]

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

On 01/31/2011 05:23 PM, Dominick Grift wrote:
> 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?
> 

another option (workaround) may or may not be to add this (empty) file
.k5login to /etc/skel in hopes that it automatically gets restored when
it gets created (copied over) when a new linux login is created.

The solution depends on your requirements and on whatever creates the
file i suspect.

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

iEYEARECAAYFAk1G4ucACgkQMlxVo39jgT8ieQCfaYRQwS5srENSc/5AZ68A635r
7pMAoKQfNdtOwwsuwCInuW0Orj4y0arD
=qxwL
-----END PGP SIGNATURE-----