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@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).
PPS: I'm using: selinux-policy-targeted-3.7.19-54.el6.noarch
-----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@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 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@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.
- What program that is executed by users creates this ~/.k5login file
(if any)
- 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
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.
Assigning a context that differs from the default should be a SELinux-protected operation, IMHO.
(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. :(
- 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.
Thanks again for your reply. It has improved quite a lot my understanding of SELinux.
-----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. :(
- 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.
/etc/selinux/restorecond.conf ?
Cheers, Vadym On Jan 31, 2011 12:35 PM, "Dominick Grift" domg472@gmail.com wrote:
-----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. :(
- 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-----
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Vadym,
/etc/selinux/restorecond.conf ?
I've been suggested this one as well off-list (maybe because of a submitter's mistake).
I'm going for a hybrid situation:
- restorecon where I can manipulate the code, since I can't predict all the files that will be affected.
- restorecond.conf where I can't manipulate the code, as issues appear.
Thanks a lot for your answers.
On Mon, Jan 31, 2011 at 18:19:12 +0100, Luis Fernando Muñoz Mejías Luis.Fernando.Munoz.Mejias@cern.ch wrote:
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.
The issue is that the file context list used by restorecon isn't really integrated into the rest of policy. Doing the look up when doing all file creations would be very expensive. So the only information currently used at creation time is the context of the directory the file is being created in, the context of the process doing the creation and the type (char, block, dir, etc.) of object being created.
However down the road the final part of of the pathname may become usable which would help in cases like this. See: http://lwn.net/Articles/419161/
Well, this is an instructive mailing list. :)
The issue is that the file context list used by restorecon isn't really integrated into the rest of policy. Doing the look up when doing all file creations would be very expensive.
I understand. Thanks for telling.
However down the road the final part of of the pathname may become usable which would help in cases like this. See: http://lwn.net/Articles/419161/
Good article. Such a feature would solve a number of headaches in our environment (independently of the correct way to implement it).
Cheers.
selinux@lists.fedoraproject.org
-
Bruno Wolff III -
Dominick Grift -
Luis Fernando Muñoz Mejías -
Vadym Chepkov