-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm slowly getting deeper into the SELinux internals. Hence, my
questions will be quite kernel related. But I hope this list is still
considered the right place for such questions, isn't it?
The notation X:t1 shall be X has/is running with type t1.
How are file descriptors associated with files regarding their labels?
1. Consider a file f:t2 is opened by p1:t1 for writing through file
descriptor fd3.
=> Which label has fd3 now? t1 or t2?
2. Consider a file f is created for writing by p1:t1 in directory d:t2
with fd=3.
=> Which label has f? And which label has fd3?
Regards,
Martin.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOC1uJAAoJEGpTkDITRjmoJAYH/21h8teiEbXbHutrmQ/jucnG
3Ky1MmMy6VfjUkBNuFIvswQWaunnrsouyx8+Iugcl1mMMV9WTp+fiFo84C7Wd6E5
5K2WJKYe5rtiPptBK+AGpKgQKOf2hao+LMozskvn/SK6gokGmppEac1J5AzhWd7g
lvAyDr5McvEEjGGiPIM+jbbFF+6drph4tZmOa9qcBSazHsRNK5rqtKuqL/9bqIGT
rV2bWA5OLOCtpXUMbF+umeN34sswrzEH8iIO5CMtPUNzNsYnhP6r3jGx98L+deNP
MPz9ode9IYVSUoAQxd3/kmxWbsdpVdqWJ6f6aGVkc1NW4cNf8VWB6wKI82cqwBM=
=DjV9
-----END PGP SIGNATURE-----
Hi Martin
> Date: Wed, 29 Jun 2011 19:06:24 +0200
> From: martin.christian at secunet.com
> To: refpolicy at oss.tresys.com
> Subject: [refpolicy] Type enforcement on files and their fds
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I'm slowly getting deeper into the SELinux internals. Hence, my
> questions will be quite kernel related. But I hope this list is still
> considered the right place for such questions, isn't it?
Good for you :-)
The refpolicy mailing list you are using now are for discussions about refpolicy package development. For any discussion about SELinux userspace development such as libsepol or any SELinux tools and SELinux kernel space development should better go to the selinux mailing list.
>
> The notation X:t1 shall be X has/is running with type t1.
>
> How are file descriptors associated with files regarding their labels?
File descriptors and file stored on the storage devices are of two different object, each may have its own label: file_security_struct.sid and inode_security_struct.sid. Generally speaking file descriptors inherits the domain of its creator.
[root/sysadm_r/s0@~]# id -Z
root:sysadm_r:sysadm_t:s0-s15:c0.c1023
[root/sysadm_r/s0@~]# ls -Z /proc/self/fd
lrwx------ root root root:sysadm_r:sysadm_t:s0-s15:c0.c1023 0 -> /dev/console
lrwx------ root root root:sysadm_r:sysadm_t:s0-s15:c0.c1023 1 -> /dev/console
lrwx------ root root root:sysadm_r:sysadm_t:s0-s15:c0.c1023 2 -> /dev/console
lr-x------ root root root:sysadm_r:sysadm_t:s0-s15:c0.c1023 3 -> /proc/419/fd
[root/sysadm_r/s0@~]# ls -Z /dev/console
crw--w---- root tty root:object_r:user_tty_device_t:s0 /dev/console
[root/sysadm_r/s0@~]#
In the above example, we can see that stdin/stdout/stderr of the current shell process share the same label of sysadm_t. However, the real input/output device(file) used is /dev/console, which has the label of user_tty_device_t.
The domain would have to be granted all required privileges to access both the file itself and the file descriptors.
>
> 1. Consider a file f:t2 is opened by p1:t1 for writing through file
> descriptor fd3.
> => Which label has fd3 now? t1 or t2?
t1.
>
> 2. Consider a file f is created for writing by p1:t1 in directory d:t2
> with fd=3.
> => Which label has f? And which label has fd3?
Normally the file would inherit the label from its current directory, so its label could be t2. However, this could be overridden by a matching type_transition rule. For example, the pid file created by syslogd in /var/run/ is labeled as syslogd_var_run_t, rather than var_run_t, this is resulted from below type_transition rule:
[root/sysadm_r/s0@~]# sesearch -SCT -s syslogd_t -t var_run_t -c file
Found 1 semantic te rules:
type_transition syslogd_t var_run_t : file syslogd_var_run_t;
[root/sysadm_r/s0@~]# ls -Z /var/run/syslogd.pid
-rw------- root root system_u:object_r:syslogd_var_run_t:s15:c0.c1023 /var/run/syslogd.pid
[root/sysadm_r/s0@~]#
Above behavior is implemented in security_compute_sid() in services.c in kernel(newcontext.type = tcontext->type, for non-process or non-socket objects).
Thanks,
Harry
>
> Regards,
>
> Martin.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOC1uJAAoJEGpTkDITRjmoJAYH/21h8teiEbXbHutrmQ/jucnG
> 3Ky1MmMy6VfjUkBNuFIvswQWaunnrsouyx8+Iugcl1mMMV9WTp+fiFo84C7Wd6E5
> 5K2WJKYe5rtiPptBK+AGpKgQKOf2hao+LMozskvn/SK6gokGmppEac1J5AzhWd7g
> lvAyDr5McvEEjGGiPIM+jbbFF+6drph4tZmOa9qcBSazHsRNK5rqtKuqL/9bqIGT
> rV2bWA5OLOCtpXUMbF+umeN34sswrzEH8iIO5CMtPUNzNsYnhP6r3jGx98L+deNP
> MPz9ode9IYVSUoAQxd3/kmxWbsdpVdqWJ6f6aGVkc1NW4cNf8VWB6wKI82cqwBM=
> =DjV9
> -----END PGP SIGNATURE-----
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110630/c0bf8b86/attachment.html