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.