Re: The concept of unconfined_t

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux