-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/08/2010 12:11 AM, Jorge Fábregas wrote: > Hi, > > I'm wondering about unconfined_t... > > Is it that, for unconfined_t, there are a bunch of "allow rules" for every > type of object and every available type? Is there anything unconfined_t can't > do? in theory unconfined cannot: execmem, execmod, execstack, execheap by default. In practice this can be worked around by toggling the allow_execmem, allow_execstack booleans respectively. Also objects can be labelled with type textrel_shlib_t to allow execmod which is done pretty often. The concept of unconfined_t is that like the name suggests, this user domain should be unconfined. In practice its not that straightforward For example the memory protections i described above aren't always allowed by unconfined_t. Then there is the problem that unconfined_t needs to create files with proper labels , and to do this it sometimes has to transition out of the unconfined domain. How it generally works: lets look at an example of how unconfined_t gets unconfined access to for example files. In the files.te source policy module there is a section that allows "unconfined access to the files module". http://oss.tresys.com/projects/refpolicy/browser/policy/modules/kernel/files.te (starts at line 214) Basically attribute is declared in this case files_unconfined_type and this attribute gets full access to the attribute file_type, which is an attribute that is assigned to all file objects. Its in the files_type() interface that is called by many other interfaces. In the the files.if interface file, a interface is provided that attaches the files_unconfined_type attribute to whatever domain calling it: http://oss.tresys.com/projects/refpolicy/browser/policy/modules/kernel/files.if (starts at line 5830) So basically unconfined_t calls files_unconfined(). And thus gets the attribute files_unconfined_type, which has unconfined access to file_type attribute file objects. Hows that done: in the unconfined.if source policy module theres two interfaces defined, that can be called by domain, and that make these calling domain unconfined, http://oss.tresys.com/projects/refpolicy/browser/policy/modules/system/unconfined.if on line 43 the files_unconfined interface is called, providing unconfined access to files (file_type) the unconfined_domain_noaudit interface which has files_unconfined included is then called in the interface unconfined_domain() just bellow: (line 124) And then the unconfined_domain() interface is called in unconfined.te source policy module: http://oss.tresys.com/projects/refpolicy/browser/policy/modules/system/unconfined.te (line 42) eventually this is what happened (with regard to unconfined_t): > # Create/access any file in a labeled filesystem; > 220 allow unconfined_t file_type:{ file chr_file } ~execmod; > 221 allow unconfined_t file_type:{ dir lnk_file sock_file fifo_file blk_file } *; > 222 > 223 # Mount/unmount any filesystem with the context= option. > 224 allow unconfined_t file_type:filesystem *; > 225 > 226 tunable_policy(`allow_execmod',` > 227 allow unconfined_t file_type:file execmod; > 228 ') Note this example is based off of refpolicy, fedora policy may differ a bit but the concept is the same. Many modules have a attribute and section that provides unconfined access to that particular module. You can get unconfined access to it by attaching this attribute to your domain type. example unconfined access to devices for the "joe_t" user domain: dev_unconfined(joe_t) > Thanks, > Jorge > -- > selinux mailing list > selinux@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/selinux -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkz/UEsACgkQMlxVo39jgT+giwCgsdBShwQ1eqVT+b7ClYK2B5zm Tn4AnjnQHHZXLFbgA+OKX4K6+8is12gY =QVzF -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
