what do we do with user_home_t, and what more could we do with it?

[Matthew Miller]

There is some concern on the devel mailing list about user-writable
directories in the default $PATH -- initially discussion about ~/.local/bin
as a hidden file, but now also out to ~/bin as well. I notice that these are
home_bin_t. What does this do with the current policy, and what more could
we do? (Particularly, a compromised application shouldn't be able to put
binaries there, but a shell script or something like `pip install` probably
_should_ be able to.)

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Bruno Wolff III]

On Wed, Oct 30, 2013 at 10:11:39 -0400,
   Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
> There is some concern on the devel mailing list about user-writable
> directories in the default $PATH -- initially discussion about ~/.local/bin
> as a hidden file, but now also out to ~/bin as well. I notice that these are
> home_bin_t. What does this do with the current policy, and what more could
> we do? (Particularly, a compromised application shouldn't be able to put
> binaries there, but a shell script or something like `pip install` probably
> _should_ be able to.) 
As was also pointed out in that thread, if you are going to worry about 
those directories, you should also worry about dot files used when starting 
up shells (.login, .cshrc, .profile and the like).

[Dominick Grift]

On Wed, 2013-10-30 at 09:50 -0500, Bruno Wolff III wrote:
>  On Wed, Oct 30, 2013 at 10:11:39 -0400,
>     Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  >There is some concern on the devel mailing list about user-writable
>  >directories in the default $PATH -- initially discussion about ~/.local/bin
>  >as a hidden file, but now also out to ~/bin as well. I notice that these are
>  >home_bin_t. What does this do with the current policy, and what more could
>  >we do? (Particularly, a compromised application shouldn't be able to put
>  >binaries there, but a shell script or something like `pip install` probably
>  >_should_ be able to.)
>  
>  As was also pointed out in that thread, if you are going to worry about 
>  those directories, you should also worry about dot files used when starting 
>  up shells (.login, .cshrc, .profile and the like).
>  -- 
Just give those a private type as well, allow user domains full access
to content with the private type, and restrict targeted applications
access to content with that type.

I actually implemented a policy module that does just that for fedora
19, although i haven't maintained it in the last couple months so it may
have developed bugs in the mean while

https://github.com/mypublicrepositories/myloginuser

video related:

https://www.youtube.com/watch?v=EUpxCXGluBI

[Matthew Miller]

On Wed, Oct 30, 2013 at 09:50:58AM -0500, Bruno Wolff III wrote:
>  >There is some concern on the devel mailing list about
> user-writable
>  >directories in the default $PATH -- initially discussion about ~/.local/bin
>  >as a hidden file, but now also out to ~/bin as well. I notice that these are
>  >home_bin_t. What does this do with the current policy, and what more could
>  >we do? (Particularly, a compromised application shouldn't be able to put
>  >binaries there, but a shell script or something like `pip install` probably
>  >_should_ be able to.)
>  As was also pointed out in that thread, if you are going to worry
>  about those directories, you should also worry about dot files used
>  when starting up shells (.login, .cshrc, .profile and the like). 
Right, I was the one who pointed that out in that thread. And, sure, let's
worry about them too. What can SELinux do for us?

-- 
Matthew Miller           mattdm(a)mattdm.org          <http://mattdm.org/>

[Daniel J Walsh]

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

On 10/30/2013 11:09 AM, Matthew Miller wrote:
>  On Wed, Oct 30, 2013 at 09:50:58AM -0500, Bruno Wolff III wrote:
> >> There is some concern on the devel mailing list about user-writable 
> >> directories in the default $PATH -- initially discussion about
> >> ~/.local/bin as a hidden file, but now also out to ~/bin as well. I
> >> notice that these are home_bin_t. What does this do with the current
> >> policy, and what more could we do? (Particularly, a compromised
> >> application shouldn't be able to put binaries there, but a shell script
> >> or something like `pip install` probably _should_ be able to.)
> > As was also pointed out in that thread, if you are going to worry about
> > those directories, you should also worry about dot files used when
> > starting up shells (.login, .cshrc, .profile and the like).
>  
>  Right, I was the one who pointed that out in that thread. And, sure, let's 
>  worry about them too. What can SELinux do for us?
>   
Well currently we don't allow confined apps to write to those files if at all
possible.  Those files are labeled user_home_t and types like mozilla_plugin_t
and chrome_sandbox_t are not allowed to write user_home_t.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJxIlAACgkQrlYvE4MpobNAEACg4ilpZyax/snyDncu0mn696sg
> vY8An1d6duw02sF/jTP3oAAg4NI08rPi
> =WJmM
> -----END PGP SIGNATURE-----

[Dominick Grift]

On Wed, 2013-10-30 at 10:11 -0400, Matthew Miller wrote:
>  There is some concern on the devel mailing list about user-writable
>  directories in the default $PATH -- initially discussion about ~/.local/bin
>  as a hidden file, but now also out to ~/bin as well. I notice that these are
>  home_bin_t. What does this do with the current policy, and what more could
>  we do? (Particularly, a compromised application shouldn't be able to put
>  binaries there, but a shell script or something like `pip install` probably
>  _should_ be able to.)
>   
home_bin_t, i believe was implemented so that select system services
would be able to run executable files with that type ( usually generic
binaries in user home directories )

>  # sesearch -ASCT -t home_bin_t -p execute_no_trans | grep home_bin_t
>     allow postfix_local_t home_bin_t : file { ioctl read getattr execute execute_no_trans
> open } ; 
>     allow procmail_t home_bin_t : file { ioctl read getattr execute execute_no_trans open
> } ;  
I looks like postfix_loca_t, and procmail_t were the reason to implement this executable
user home type


What we could to is target applications, the user domain itself will eventually need full
access to all user home content types.

So , what do?

Make the user run targeted applications outside of the user domain.

Then we can allow those targeted applications, if it makes sense, pretty much full access
to generic user content, and
restrict access to non-generic content ( for instance home_bin_t )

[Daniel J Walsh]

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

On 10/30/2013 10:11 AM, Matthew Miller wrote:
>  There is some concern on the devel mailing list about user-writable 
>  directories in the default $PATH -- initially discussion about
>  ~/.local/bin as a hidden file, but now also out to ~/bin as well. I notice
>  that these are home_bin_t. What does this do with the current policy, and
>  what more could we do? (Particularly, a compromised application shouldn't
>  be able to put binaries there, but a shell script or something like `pip
>  install` probably _should_ be able to.)
>   
I responded on the other email on what these labels do.

Confining user space is difficult, since most people do not want stuff to
break and blocking apps from writing general places in the homedir is difficult.

I think the future with confined applications where the application runs
within a container and does not get direct access to the users homedir is the
only way to handle this.

Imaging firefox running with its own home dir but when user wants to upload a
file or download a file, firefox asks the desktop to launch the file dialog,
which runs in a separate process controlled by the user.  The user then
specifies the file location and file dialog process opens fd or creates fd and
passes fd into the firefox container.  Now the firefox app can write the FD,
but it would not be able to get to ~/bin or ~/.local/bin within the users home
dir.

Until we get to this type of architecture it is very difficult to confine
large apps like Libreoffice, Firefox, Thunderbird, Evolution ...

Personally I think if you are going to put ~/bin or ~/.local/bin into the
users path they should be at the end of the path rather then the front.  Then
the user has less chance of executing the wrong executable.  Like the mkdir
example, but he can still execute applications in his homedir.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJxIgYACgkQrlYvE4MpobNGTQCdFAEHTzj2s5JxwruHztB8+ZMl
> wFIAn0J2wpk3cJDrVCoEYTU3MNXZVjbh
> =3ox7
> -----END PGP SIGNATURE-----

[Dominick Grift]

On Wed, 2013-10-30 at 11:13 -0400, Daniel J Walsh wrote:
>  On 10/30/2013 10:11 AM, Matthew Miller wrote:
>  > There is some concern on the devel mailing list about user-writable 
>  > directories in the default $PATH -- initially discussion about
>  > ~/.local/bin as a hidden file, but now also out to ~/bin as well. I notice
>  > that these are home_bin_t. What does this do with the current policy, and
>  > what more could we do? (Particularly, a compromised application shouldn't
>  > be able to put binaries there, but a shell script or something like `pip
>  > install` probably _should_ be able to.)
>  > 
>  I responded on the other email on what these labels do.
>  
>  Confining user space is difficult, since most people do not want stuff to
>  break and blocking apps from writing general places in the homedir is difficult.
>  
>  I think the future with confined applications where the application runs
>  within a container and does not get direct access to the users homedir is the
>  only way to handle this. 
Difficult: sure, impossible: i do not think so.

I have proof that it is possible, if one sets clear goals, boundaries,
and realistic expectations.

I do not think containers are a silver bullet, and that MCS is a
solution to all problems.

[Daniel J Walsh]

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

On 10/30/2013 11:43 AM, Dominick Grift wrote:
>  On Wed, 2013-10-30 at 11:13 -0400, Daniel J Walsh wrote:
> > On 10/30/2013 10:11 AM, Matthew Miller wrote:
> >> There is some concern on the devel mailing list about user-writable 
> >> directories in the default $PATH -- initially discussion about 
> >> ~/.local/bin as a hidden file, but now also out to ~/bin as well. I
> >> notice that these are home_bin_t. What does this do with the current
> >> policy, and what more could we do? (Particularly, a compromised
> >> application shouldn't be able to put binaries there, but a shell script
> >> or something like `pip install` probably _should_ be able to.)
> >> 
> > I responded on the other email on what these labels do.
> > 
> > Confining user space is difficult, since most people do not want stuff
> > to break and blocking apps from writing general places in the homedir is
> > difficult.
> > 
> > I think the future with confined applications where the application runs 
> > within a container and does not get direct access to the users homedir is
> > the only way to handle this.
>  
>  Difficult: sure, impossible: i do not think so.
>  
>  I have proof that it is possible, if one sets clear goals, boundaries, and
>  realistic expectations.
>  
>  I do not think containers are a silver bullet, and that MCS is a solution
>  to all problems.
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   
Well in this case I would like to potentially run these container/apps with
Types like firefox_t and ooffice_t, but more generically with app_t where
app_t is not allowed to touch user_home_t.

But we are going far a field of this email chain, and we can revisit this when
we actually have applications containers.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJxK14ACgkQrlYvE4MpobOdVwCfYeAIAsaqDPi71RuvfmeqY54B
> hcgAn0ufeGqXYggf4F3EYbDo/YVZPIFw
> =z5I7
> -----END PGP SIGNATURE-----

[Dominick Grift]

On Wed, 2013-10-30 at 11:53 -0400, Daniel J Walsh wrote:

>  Well in this case I would like to potentially run these
> container/apps with
>  Types like firefox_t and ooffice_t, but more generically with app_t where
>  app_t is not allowed to touch user_home_t.
>  
>  But we are going far a field of this email chain, and we can revisit this when
>  we actually have applications containers.
>  
>   
Sure, we will see, and yes i guess containers in Gnome are inevitable
anyways (what about other DE's). I think, but you probably already know
that, that we should not try to prevent access to the generic user home
content type user_home_t, but instead classify everything that is not
generic.

Anyways the difference is that i have integrity enforcement on the
desktop currently implemented (albeit somewhat limited), and what you
are suggesting is something that might work in a distant future.

</thread>

[Miroslav Grepl]

On 10/30/2013 05:07 PM, Dominick Grift wrote:
>  On Wed, 2013-10-30 at 11:53 -0400, Daniel J Walsh wrote:
>
> > Well in this case I would like to potentially run these container/apps with
> > Types like firefox_t and ooffice_t, but more generically with app_t where
> > app_t is not allowed to touch user_home_t.
> >
> > But we are going far a field of this email chain, and we can revisit this when
> > we actually have applications containers.
> >
> >
>  Sure, we will see, and yes i guess containers in Gnome are inevitable
>  anyways (what about other DE's). I think, but you probably already know
>  that, that we should not try to prevent access to the generic user home
>  content type user_home_t, but instead classify everything that is not
>  generic. 
And do you think it is really possible?
>  Anyways the difference is that i have integrity enforcement on the
>  desktop currently implemented (albeit somewhat limited), and what you
>  are suggesting is something that might work in a distant future.
>
>  </thread>
>
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Dominick Grift]

On Fri, 2013-11-01 at 10:41 +0100, Miroslav Grepl wrote:
>  On 10/30/2013 05:07 PM, Dominick Grift wrote:
>  > On Wed, 2013-10-30 at 11:53 -0400, Daniel J Walsh wrote:
>  >
>  >> Well in this case I would like to potentially run these container/apps with
>  >> Types like firefox_t and ooffice_t, but more generically with app_t where
>  >> app_t is not allowed to touch user_home_t.
>  >>
>  >> But we are going far a field of this email chain, and we can revisit this when
>  >> we actually have applications containers.
>  >>
>  >>
>  > Sure, we will see, and yes i guess containers in Gnome are inevitable
>  > anyways (what about other DE's). I think, but you probably already know
>  > that, that we should not try to prevent access to the generic user home
>  > content type user_home_t, but instead classify everything that is not
>  > generic.
>  And do you think it is really possible?
>  > 
"I have proof that it is possible, if one sets clear goals, boundaries,
and realistic expectations."

Confining the user space not that different from confining the system
space. Its just a lot more work to maintain and more error prone,
because there is more interactivity, and things change more frequently
in the the user space

But if you set clear goals, and clear boundaries (as to what you support
and what not), then yes, i know its possible because i implemented it 

The same goes for the system space, we also set boundaries there. "This
we can, and will support, and anything else not"