Correct way to create /tmp files that can be used by other domains.

[Jayson Hurst]

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.

[Dominick Grift]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Daniel J Walsh]

-----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(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLzZS4ACgkQrlYvE4MpobMJaACglrysp6rk4gyGhx9rkhdju+/r
> 8GcAoIu2IGQDt/i0KimEaERzEq4vdJEF
> =6N4d
> -----END PGP SIGNATURE-----