The concept of unconfined_t

Thu Dec 9 11:01:23 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/09/2010 10:26 AM, Dominick Grift wrote:
> On 12/09/2010 02:46 AM, Jorge Fábregas wrote:
>> 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 think Dan Walsh was referring to the communication paths in the user
space. And this is certainly a very big issue.

If you just confine a single user application like firefox, then it will
needs to communicate with the user domain. Because only firefox runs in
its own domain, and a lot of other applications that firefox may need to
interact with or communicate with run in the user domain.

That means that the user domain requires more privileges than a user
itself needs. It is for example the bluetooth applet that needs to
interact with the wireless device, but since the bluetooth applet runs
in the user domain, the user domain needs to be allowed to access the
wireless device. Even though the user does not have to interact with it
directly but some app(s) do(es)

So basically to do this effective in my opinion is cut off interaction
between the desktop layer, system layer and the user layer. user domains
cannot communicate with the other layers (except sysadm_t which needs to
manage system services.)

But to accomplish that one needs to confine everything that is used
first, and this is a lot.

In my branch i decided to start with a minimal desktop environment, only
the strictly required system services and some of the user applications
that i use. Confine those and then cut off all communication with the
user domain.

Now you have a solid base to confined user applications. Because you
will notice that in most (the goal is all) cases your confined app no
longer needs to communicate to the user domains.

Then you can also see that a normal user does no longer needs all the
privileges that the current user domain allows.

For example: unprivileged users can connect to any network port. Yet its
not the actual user connecting to the network port, instead it is an
agent connecting on behalf of the user. Since we aim to confine all
agents, user domain no longer have to be permitted to connect to the
network.

Same goes for many other aspects. Currently user domain can communicate
directly to system services like consolekit for example with dbus etc.
But users (usually) do not communicate via dbus to consolekit, its user
agents communicating over dbus on behalf of users. confine the agents
and you can drop these permissions for the user domain.

There are other benefits as well, but they dont come cheap. Before you
get to the point where you can isolate the user from the remainder of
the system you have to travel a long road. maintaining it is even more
work and its error prone. Especially in a moving target like Fedora
where things change all the time. Small changes in the user space can
break the whole system.

And what is the benefit? You can control what users can and cannot do.
You can control user application domains access to other user
application domains and their objects.

One example is gnome-keyring-daemon. It stores the keyring in
.gnome2/keyrings:

>  ls -alZ /home/dgrift/.gnome2/keyrings
> drwx------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 .
> drwx------. dgrift dgrift staff_u:object_r:gnome_home_t:s0 ..
> -rw-rw-r--. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 default
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 default.keyring
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 login.keyring
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore.4JFVMV
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore.94RDNV
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore.D3TWMV
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore.LMZ6MV
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore.MJNWMV
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore.PTGANV
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore.WYE0MV
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore.XNZVMV
> -rw-------. dgrift dgrift staff_u:object_r:gkeyringd_gnome_home_t:s0 user.keystore.YYB9MV
> [root at localhost Desktop]$ 

But who what can access it?

> sesearch --allow -SC -s domain -t gkeyringd_gnome_home_t -c file -p read
> Found 20 semantic av rules:
>    allow rpm_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename open } ; 
>    allow user_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename open } ; 
>    allow user_gkeyringd_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
>    allow sysadm_gkeyringd_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
>    allow sysadm_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename open } ; 
>    allow useradd_t user_home_type : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename open } ; 
>    allow rpm_script_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
>    allow readahead_t non_security_file_type : file { ioctl read getattr lock open } ; 
>    allow sysadm_gvfsd_trash_t user_home_type : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
>    allow staff_gvfsd_trash_t user_home_type : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
>    allow quota_t file_type : file { ioctl read getattr lock open } ; 
>    allow staff_gkeyringd_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
>    allow user_gvfsd_trash_t user_home_type : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
>    allow staff_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename open } ; 
>    allow restorecond_t gkeyringd_gnome_home_t : file { ioctl read getattr lock relabelfrom relabelto open } ; 
> DT allow nfsd_t gkeyringd_gnome_home_t : file { ioctl read getattr lock open } ; [ nfs_export_all_ro ]
> DT allow nfsd_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ nfs_export_all_rw ]
> DT allow kernel_t gkeyringd_gnome_home_t : file { ioctl read getattr lock open } ; [ nfs_export_all_ro ]
> DT allow kernel_t gkeyringd_gnome_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; [ nfs_export_all_rw ]
> DT allow mount_t gkeyringd_gnome_home_t : file { ioctl read getattr lock open } ; [ allow_mount_anyfile ]

The users can of course but besides that not many other domains can.

to put this into context:

in the above list about 14 domains can read gkeyringd_gnome_home_t files
by default. A few more can be allowed this access by toggling a boolean,

> seinfo -x -adomain | wc -l
> 705

.. yet this system counts 705 confined domains this about 650+ domains
cannot access this content.

So what you establish is more integrity in the desktop environment.

> locking down the desktop is a huge undertaking and maintaining it is as
> well. The audience for this is also limited. most fedora people do not
> want to be confined.
> 
> yet, i agree with you and this is why i maintain my own policy that aims
> to confine the whole (gnome) desktop environment. To use it is not easy
> and it is bug ridden. But it certainly works very good for me.
> 
> http://fedorapeople.org/gitweb?p=domg472/public_git/refpolicy.git;a=summary
> 
>> I haven't tried sandbox -X...I will soon.
> 
> Sandbox is neat the only issue i have with it is that usage is to the
> discretion of the user. Is also is different from confining the whole
> desktop where everything is isolated and not just firefox (or whatever
> app you run in a sandbox)
> 
> 
>> Thanks again!
>> Jorge
>> --
>> selinux mailing list
>> selinux at lists.fedoraproject.org
>> 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/

iEYEARECAAYFAk0AtwIACgkQMlxVo39jgT/hMwCgrGDLalIQTy+Jq2Qvnlu9Plcg
AmoAnAjUyxsSlcygr3sl6CNFZwE8eMr8
=X9bD
-----END PGP SIGNATURE-----