/etc/selinux/restorecond.conf ?
Cheers,
Vadym
On Jan 31, 2011 12:35 PM, "Dominick Grift" <domg472@xxxxxxxxx> 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. :(
>>
>>> 1. 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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/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. :(
>>
>>> 1. 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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
