If my daemon creates a file in /tmp which is labelled with my domains tmp file context as follows:
-rw-------. 1001 1000 unconfined_u:object_r:qasd_tmp_t:s0 /tmp/krb5cc_1001
other daemons such as sshd (which use kerberos) will need access to this file as well. Is there a way to grant that access from my policy without having to specify an exact allow rule for sshd?
I am seeing audit messages about this from audit2why.
type=AVC msg=audit(1391534896.381:2642): avc: denied { getattr } for pid=2070 comm="sshd" path="/tmp/krb5cc_1001" dev=dm-0 ino=281219 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:qasd_tmp_t:s0 tclass=file
audit2allow gives me the following allow rule:
allow sshd_t qasd_tmp_t:file { getattr unlink };
But I don't want to create specific allow rules like this if I can help it.
On Tue, 2014-02-04 at 18:03 -0700, Jayson Hurst wrote:
Not 100% sure but i suspect that instead of creating that file with a private tmp file type you should us the existing:
kerberos_tmp_filetrans_host_rcache()
This will allow your domain to create these file with a type transition to the "host_rcache" file type, which is probably accessible by other relevant parties as well.
example:
optional-policy(` kerberos_tmp_filetrans_host_rcache(qasd_t) ')
This will work if you domain only uses /tmp for these kinds of files. (e.g. any files created in tmp will get the host_rcache file type)
If your domain creates other files straight into /tmp/ as well then you may want to use the second parameter that the kerberos-tmp_filetrans_host_rcache() supports (a file name)
But that kind of sucks because the file names are semi random (suffixed with uid)
So yes you might need to be creative there
Not sure though if i got this right or if this is optimal since i dont use kerberos.
If my daemon creates a file in /tmp which is labelled with my domains tmp file context as follows:
-rw-------. 1001 1000 unconfined_u:object_r:qasd_tmp_t:s0 /tmp/krb5cc_1001
other daemons such as sshd (which use kerberos) will need access to this file as well. Is there a way to grant that access from my policy without having to specify an exact allow rule for sshd?
I am seeing audit messages about this from audit2why.
type=AVC msg=audit(1391534896.381:2642): avc: denied { getattr } for pid=2070 comm="sshd" path="/tmp/krb5cc_1001" dev=dm-0 ino=281219 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:qasd_tmp_t:s0 tclass=file
audit2allow gives me the following allow rule:
allow sshd_t qasd_tmp_t:file { getattr unlink };
But I don't want to create specific allow rules like this if I can help it.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/05/2014 02:03 AM, Jayson Hurst wrote:
If my daemon creates a file in /tmp which is labelled with my domains tmp file context as follows:
-rw-------. 1001 1000 unconfined_u:object_r:qasd_tmp_t:s0 /tmp/krb5cc_1001
other daemons such as sshd (which use kerberos) will need access to this file as well. Is there a way to grant that access from my policy without having to specify an exact allow rule for sshd?
I am seeing audit messages about this from audit2why.
type=AVC msg=audit(1391534896.381:2642): avc: denied { getattr } for pid=2070 comm="sshd" path="/tmp/krb5cc_1001" dev=dm-0 ino=281219 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:qasd_tmp_t:s0 tclass=file
audit2allow gives me the following allow rule:
allow sshd_t qasd_tmp_t:file { getattr unlink };
But I don't want to create specific allow rules like this if I can help it.
Well you really want this content to probably be labeled user_tmp_t. One problem, I see is you are creating content in /tmp that is well known name, which can be dangerous. In Fedora we are putting this type of content under /run/user/UID, rather then in /tmp.
You could make a call like setfscreatecon("system_u:object_r:user_tmp_t:s0") before creating the content.
A file name transition rule would work, but I recommend that you do not create a guessable name in /tmp.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Dominick Grift -
Jayson Hurst