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