-----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@xxxxxxx > .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----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
