On Wednesday 08 December 2010 05:30:52 Dominick Grift wrote: > 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. Thanks again Dominick. This is indeed overwhelming but nevertheless, I now have a better idea of what's behind unconfined_t (way more subtleties than expected :) Now that I'm paying more attention to SELinux - from the destkop point of view- I was surprised to find out that Firefox runs as unconfined_t. I really thought that it was confined. I spent some time using sesearch and found out there's no firefox_t or mozilla_t around. Shouldn't the most used desktop app these days - a web browser - be confined? I was going to ask about this but then I found out a blog post from Dan Walsh on "sandbox -X" where he mentions the difficulties of locking down Firefox or any other desktop app. I haven't tried sandbox -X...I will soon. Thanks again! Jorge -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
