Desktop apps interoperability

[Ivan Gyurdiev]

Okay, mozilla's handling of saved files is a problem. Here's what it
does - files saved under ROLE_home_dir_t, or ROLE_home_t directories
turn to ROLE_mozilla_home_t via file_type_auto_trans.

Here's what gift does by default - it has a download folder where it
puts stuff. The downloaded files turn to ROLE_gift_home_t (context of
parent folder, which is ~/.giFT/completed or something).

Here's what mencoder does - it saves stuff as ROLE_mplayer_home_t
via file_type_auto_trans.

==============

This is bad for interoperability. Using the home_domain macro,
the user has access to the home_domain type of an application.
However one app has no access to the home_domain type of another app.
Basically I can never play (mplayer) a movie that I just downloaded,
whether or not it was via mozilla, or gift. 

Alternatively, there could be a common data type - ROLE_home_t.
However none of those apps can save its data directly
under /home/username as ROLE_home_t, because all of them have a
home_domain, and that's where the file_type_auto_trans rule is used.
There can't be more than one file_type_auto_trans on the same folder
type (right?). Furthermore this seems to be explicitly avoided for
mozilla (it does not write to ROLE_home_t for security reasons -
overwriting .bashrc?).

============

Ok, here


Fundamentally, what I want to know is:

1) Do desktop apps need to be confined? Is it a good idea to confine
them?

2) If so, a shared data type is needed for interoperability. 
Is ROLE_home_t acceptable for that purpose.

3) 

0) No 

1) Shared data type is needed for interoperability

2) Keeping both application settings, and user data in the same folder
is a problem

[Ivan Gyurdiev]

Okay that was an unfinished email - sorry for my stupidity - I was 
editing it and changing things and clicked send by mistake.

The problem is accurately described (in the first part of the email) and
what I was getting to - I'm trying to imagine how desktop apps can be
confined properly in the future (and right now, for that matter). How
will they interoperate and share data?

I was thinking of a ~/downloads folder with a shared context, but 
this makes sense for apps that download stuff. In the future if desktop
apps are confined (say openoffice, abiword) this becomes a more generic
problem.

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Ivan Gyurdiev]

On Mon, 2005-03-28 at 00:03 -0500, Ivan Gyurdiev wrote:
>  Okay that was an unfinished email - sorry for my stupidity - I was 
>  editing it and changing things and clicked send by mistake.
>  
>  The problem is accurately described (in the first part of the email) and
>  what I was getting to - I'm trying to imagine how desktop apps can be
>  confined properly in the future (and right now, for that matter). How
>  will they interoperate and share data?
>  
>  I was thinking of a ~/downloads folder with a shared context, but 
>  this makes sense for apps that download stuff. In the future if desktop
>  apps are confined (say openoffice, abiword) this becomes a more generic
>  problem. 
Part of the problem seems to be the way Linux apps treat /home, as the
place for everything. Why are both app. settings and user data stored
in /home as the default location. That's where the problem comes from,
and that seems like a bad idea - the user doesn't care about app
settings and system files - they are not to be edited directly. That's
why they're hidden in the first place. 

Now Windows' approach of having "My Documents" and the like is starting
to make a lot of sense (even though I absolutely hate those names).

If app settings were kept separate, in a non-selinux environment you
could export your data files w/out exporting hidden important files like
your gpg keys. 

If app settings were kept separate, you could restorecon those settings
to correct contexts. Dwalsh said restorecon skips /home today because
it could accidentaly reveal out-of-place gpg keys, or because it might
be really big. Both those problems would not apply if settings were in a
separate place - you could just restorecon the settings.

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Luke Kenneth Casson Leighton]

On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:

>  Now Windows' approach of having "My Documents" and the
> like is starting
>  to make a lot of sense (even though I absolutely hate those names). 
 and the concept of a registry, too.

 unix has a lot of legacy headaches to answer for that make its
 useability as a desktop system a pain in the neck.

 perhaps this is one that's worthwhile raising with the linux
 standards base people?

 if it doesn't present a solution "now" it might at least get one into
 the pipeline and start to make a difference in five to ten years time.

 l.

[Rogelio Serrano]

On Mon, 28 Mar 2005 11:01:40 +0100, Luke Kenneth Casson Leighton
<lkcl(a)lkcl.net&gt; wrote:
>  On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:
>  
>  > Now Windows' approach of having "My Documents" and the like is
> starting
>  > to make a lot of sense (even though I absolutely hate those names).
>  
>   and the concept of a registry, too.
>  
>   unix has a lot of legacy headaches to answer for that make its
>   useability as a desktop system a pain in the neck.
>  
>   perhaps this is one that's worthwhile raising with the linux
>   standards base people?
>  
>   if it doesn't present a solution "now" it might at least get one into
>   the pipeline and start to make a difference in five to ten years time.
>  
>   l.
>   
NextStep and Mac OS X solved this problem very elegantly. IMHO.  


-- 
Blood is thicker than water... and much tastier
                                           John Davidorff Pell

[Dale Amon]

On Mon, Mar 28, 2005 at 06:17:14PM +0800, Rogelio Serrano wrote:
>  On Mon, 28 Mar 2005 11:01:40 +0100, Luke Kenneth Casson Leighton
>  <lkcl(a)lkcl.net&gt; wrote:
>  > On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:
>  > 
>  > > Now Windows' approach of having "My Documents" and the like is
> starting
>  > > to make a lot of sense (even though I absolutely hate those names).
>  > 
>  >  and the concept of a registry, too.
>  > 
>  >  unix has a lot of legacy headaches to answer for that make its
>  >  useability as a desktop system a pain in the neck.
>  > 
>  >  perhaps this is one that's worthwhile raising with the linux
>  >  standards base people?
>  > 
>  >  if it doesn't present a solution "now" it might at least get one
> into
>  >  the pipeline and start to make a difference in five to ten years time.
>  > 
>  >  l.
>  > 
>  
>  NextStep and Mac OS X solved this problem very elegantly. IMHO.   
I will run screaming if someone imports the registry
concept into Unix. You'll need full AI to get it right.
I managed a moderate size university network of NeXT's.
The admin interface seems nice at first... but it sucks
you in and then you find the problems with upgrades of
software; the problem that if you pulled the plug on 
UFS open files got corrupted... and guess what? The
netinfo files were almost always open! 

Keep it ASCII; keep it in seperate files. By all means
try to get application and daemon writers to standardize
on their parsing. Not that you ever will.

And has to My Documents? Yech. Every user has their
own private idea of what setups should exist. Users
are users and have their own little worlds; Root
is Root and never the twain shall meet. Except perhaps
with proper selinux controls...

Now I do wish there were a dotfile directory in each
home directory and everyone put the dotfiles in it
when they are created... but if wishes were fishes
I'd have a life time supply of fish'n'chips.

-- 
------------------------------------------------------
   Dale Amon     amon(a)islandone.org    [phone]
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

[Stephen Smalley]

On Tue, 2005-03-29 at 12:33 +0100, Dale Amon wrote:
>  I will run screaming if someone imports the registry
>  concept into Unix. 
Better start running then.  gconf is already being used as a registry,
and there is a linux registry aka elektra project as well.

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Colin Walters]

On Tue, 2005-03-29 at 08:54 -0500, Stephen Smalley wrote:
>  On Tue, 2005-03-29 at 12:33 +0100, Dale Amon wrote:
>  > I will run screaming if someone imports the registry
>  > concept into Unix.
>  
>  Better start running then.  gconf is already being used as a registry,
>  and there is a linux registry aka elektra project as well. 
People very often confuse "the registry concept" with a specific
implementation which they may have had a bad experience with in the past
or have heard rumors of other people having a bad experience with.

Having some sort of sane mechanism for locating, managing, and
monitoring preferences is pretty critical to writing desktop
applications.  For example, one thing that GConf provides is
notification of preference changes.  This is a fundamental basis for a
lot of how GNOME's "instant-apply" feature works, e.g. if you change the
theme all apps automatically update.  Doing this kind of thing with
"text files" or whatever is going to be hackish at best.

To bring this discussion somewhat back on topic, Luke is right in that
in order to write a strong SELinux policy for desktop applications, we
really need to have fine-grained separation between user data (i.e.
OpenOffice documents), user preferences, highly sensitive data such as
GPG keys, and random other junk that apps dump in $HOME like error logs.

Also relating to the registry: Once we finish D-BUS, the plan is to make
GConf be a userspace object manager; for example, to allow Mozilla the
ability to read but not write the "http proxy" GConf key, or to disallow
it from reading the WEP keys that NetworkManager currently stores there
(which is wrong, but...).  Having fine-grained labeling on preference
keys is much nicer than granting user_mozilla_t access to user_home_t,
which grants kind of unconstrained read access to everything, and is
better than trying to maintain a text file per key in some hypothetical
"text file registry" just so that we can have individual labels on them.

[Mike Hearn]

On Tue, 29 Mar 2005 10:39:58 -0500, Colin Walters wrote:
>  Also relating to the registry: Once we finish D-BUS, the plan is to
> make
>  GConf be a userspace object manager 
You mean making GConf an "AVC" so you can label keys with SELinux
contexts? Or do you mean something separate to SELinux?

SELinux GConf integration would totally rule, I hope that's what you mean :)

thanks -mike

[Tom]

On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:
>  Part of the problem seems to be the way Linux apps treat /home, as
> the
>  place for everything.  
It doesn't. It treats $HOME as the only place that the user has
permission to store his stuff. On a well-configured system, that
assumption is correct.


>  Why are both app. settings and user data stored
>  in /home as the default location.  
Because otherwise the user couldn't add or edit them.


>  Now Windows' approach of having "My Documents" and the
> like is starting
>  to make a lot of sense (even though I absolutely hate those names). 
The Linux approach, however, allows much more flexibility.

If you want applications to share data, there are several ways to
accomplish that goal. Here's just a quick idea:

* add $HOME/Downloads as a directory
* give it its own type, maybe ROLE_downloads_t
* give mozilla permissions to write there, with file_type_auto_trans
* give mplayer permissions to the resulting files

voila, mplayer can now play stuff downloaded from the web, without
opening up the big hole of giving it permissions to all mozilla files.


Another solution, for a more paranoid environment would be adding a
virus/malware scanner domain that can read mozilla's files and write them 
out again (after checking and/or cleaning) as a regular ROLE_home_t
file. This would ensure that any files fully accessible in the home
directory have been scanned.



The point is - I may or may not want mplayer to play random stuff from
the web with potentially dangerous content. If you want to, evaluate
your security requirements and institute the appropriate solution.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom(a)lemuria.org&gt;
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

[Ivan Gyurdiev]

On Mon, 2005-03-28 at 13:26 +0200, Tom wrote:
>  On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan Gyurdiev wrote:
>  > Part of the problem seems to be the way Linux apps treat /home, as the
>  > place for everything. 
>  
>  It doesn't. It treats $HOME as the only place that the user has
>  permission to store his stuff. On a well-configured system, that
>  assumption is correct. 
Ah, but that's not true. The user is actively encouraged to store stuff
in $HOME, and not elsewhere, because:

1) There's no other folder that exists. The average user makes use of
what's already there.

2) The GNOME desktop has a large home icon where you put your files.

3) All applications that have a save dialog open /home as the default.

4) It's designated as a place to store your files in the GNOME Places

5) There's no easy way to export files you care about (minus settings)
through Samba, while there is an automatic HOME share you get for /home.

6) From a SELinux viewpoint, why does the user domain *need* access
to /home's setting part at all? Those are files created w/out direct
user interaction. They could be made accessible to individual
application domains, without user_t selinux access. 

Anyway, more to the point:

7) I can't call file_type_auto_trans twice on the same folder.

>  If you want applications to share data, there are several ways to
>  accomplish that goal. Here's just a quick idea:
>  
>  * add $HOME/Downloads as a directory
>  * give it its own type, maybe ROLE_downloads_t
>  * give mozilla permissions to write there, with file_type_auto_trans
>  * give mplayer permissions to the resulting files 
...that's what I already proposed, but I'm saying that:

A) In the future if all desktop apps are restricted, this folder will
have to become something more generic that doesn't have anything to do
with downloads. It would become the equivalent of a new /home where you
keep your files. Are there any plans to restrict desktop apps ?

B) Whatever is decided upon needs to work out of the box. It needs to be
the default way things work, as opposed to me having to jump through
hoops to make SElinux work. Otherwise the average user will just disable
any protection and not look back.

>  voila, mplayer can now play stuff downloaded from the web, without
>  opening up the big hole of giving it permissions to all mozilla files. 
Actually now I remember mplayer actually does have access to mozilla
files... but as you say that is a hack, which shouldn't be there.
However mplayer doesn't have access to gift files, which is what I was
thinking of. 

>  The point is - I may or may not want mplayer to play random stuff
> from
>  the web with potentially dangerous content. If you want to, evaluate
>  your security requirements and institute the appropriate solution. 
This email was titled "Desktop apps interoperability". It implies that
we're talking about the average desktop, as opposed to a paranoid
environment. The average person does not know (or care) for evaluating
security requirements and dealing with selinux. He/she wants
transparency, but there's still value in using selinux.

If you choose to download the content in question, and choose to run
mplayer on it, then it seems to me that it should work without messing
with security contexts.

--------

In the short run a downloads folder sounds like a good idea to me.
If added to skel, and set as the default download folder for mozilla,
that would be an improvement, I think. 

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Tom]

>  > It doesn't. It treats $HOME as the only place that the user
> has
>  > permission to store his stuff. On a well-configured system, that
>  > assumption is correct.
>  
>  Ah, but that's not true. The user is actively encouraged to store stuff
>  in $HOME, and not elsewhere, because: 
Because there are many reasons for that. The most important ones
in my book are:

* other locations might be mounted read-only
* /home may be a remote (e.g. NFS) mount
* various standards define what /usr or /var are for, and storing
  user-specific data is not on that list
* security - seperation between system and user data

That last one is the one that we don't want to break, on a SECURITY
ENHANCED Linux system least of all.



All your reasons except for #1 are really just consequences of the fact
that /home is where Unix users store their stuff.


>  6) From a SELinux viewpoint, why does the user domain *need* access
>  to /home's setting part at all? Those are files created w/out direct
>  user interaction. They could be made accessible to individual
>  application domains, without user_t selinux access.  
These are files that are totally created with user interaction. Just
because Joe Dummy doesn't vi his .muttrc doesn't mean that I don't.

It also saves us the headache of writing a policy for each and every
file that stores something in $HOME - which means pretty much
everything that has an options or settings dialog.



>  Anyway, more to the point:
>  
>  7) I can't call file_type_auto_trans twice on the same folder. 
That is why I suggested a new folder for that specific purpose. I only
need one file_type_auto_trans there, namely when I store the stuff.

If I recall correctly, I had written a mozilla policy with such a
change a year or so ago.



>  A) In the future if all desktop apps are restricted, this folder
> will
>  have to become something more generic that doesn't have anything to do
>  with downloads.  
Are you insane?
Generic folders are the bane of anything even resembling security.
Being _specific_ is what SELinux is all about. That's what the ENHANCED
means, if you strip away all the bullshit bingo words. MAC and RBAC are
just the means used.

Downloads, especially, deserve to be treated differently, as they are
data from untrusted sources.



>  It would become the equivalent of a new /home where you
>  keep your files. Are there any plans to restrict desktop apps ? 
Define "restrict".

"Do their intended operation" - no, I don't think there are any plans
to prevent that.

"Mess at will with anything else in $HOME" - why yes, absolutely. If my
movie player has any reasons reading my mail preferences, I really want
to know them.



>  B) Whatever is decided upon needs to work out of the box. It needs to
> be
>  the default way things work, as opposed to me having to jump through
>  hoops to make SElinux work. Otherwise the average user will just disable
>  any protection and not look back. 
There will be hoops. Just like putting on the safety belt when getting
into your car is one.

I'm sure everyone involved in SELinux development wants to avoid
unnecessary hoops. But some will be necessary, just like a firewall,
two virus scanners and a yearly reinstall are necessary on today's
windos systems.



>  This email was titled "Desktop apps interoperability". It
> implies that
>  we're talking about the average desktop, as opposed to a paranoid
>  environment. The average person does not know (or care) for evaluating
>  security requirements and dealing with selinux. He/she wants
>  transparency, but there's still value in using selinux. 
The average person also doesn't want their home machine turned into a
spammer zombie. At the current growth rate, the average person will
soon be faced with a few hard choices. I mean, you can't seriously buy 
Windows XP anymore, because you'll be infected with at least one malware
before the download of SP2 is finished. The only option is OEM versions
that already have at least SP2 applied.



>  If you choose to download the content in question, and choose to run
>  mplayer on it, then it seems to me that it should work without messing
>  with security contexts. 
Ah, but maybe you don't want mplayer to access everything you
downloaded?

In the long term, an explicit transfer (a nice GUI tool would make it
almost painless for the user. In fact, on a drag-and-drop desktop you
could probably add it to the drag&drop process) seems to be the better
solution.




-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom(a)lemuria.org&gt;
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

[Ivan Gyurdiev]

On Mon, 2005-03-28 at 15:11 +0200, Tom wrote:
>  > > It doesn't. It treats $HOME as the only place that the
> user has
>  > > permission to store his stuff. On a well-configured system, that
>  > > assumption is correct.
>  > 
>  > Ah, but that's not true. The user is actively encouraged to store stuff
>  > in $HOME, and not elsewhere, because:
>  
>  Because there are many reasons for that. The most important ones
>  in my book are:
>  
>  * other locations might be mounted read-only
>  * /home may be a remote (e.g. NFS) mount
>  * various standards define what /usr or /var are for, and storing
>    user-specific data is not on that list
>  * security - seperation between system and user data 
I was suggesting that content should be kept in a sub-folder of /home,
not that it should be kept somewhere else. I'm sorry for the
misunderstanding. I am suggesting that this folder(s) should be
standartized somehow. I am saying that settings should be kept separate.

>  > 6) From a SELinux viewpoint, why does the user domain *need*
> access
>  > to /home's setting part at all? Those are files created w/out direct
>  > user interaction. They could be made accessible to individual
>  > application domains, without user_t selinux access. 
>  
>  These are files that are totally created with user interaction. Just
>  because Joe Dummy doesn't vi his .muttrc doesn't mean that I don't. 
That's a valid point - and the way home_domain macro currently works 
is that it allows the user to access the data. Anyway, I still think
there's advantages to keeping settings separate from "content".


>  > Anyway, more to the point:
>  > 
>  > 7) I can't call file_type_auto_trans twice on the same folder.
>  
>  That is why I suggested a new folder for that specific purpose. I only
>  need one file_type_auto_trans there, namely when I store the stuff.
>  
>  If I recall correctly, I had written a mozilla policy with such a
>  change a year or so ago. 
So let's add this folder to /skel with the appropriate context
(*different* from the current ROLE_mozilla_home_t), and make it the
default for mozilla. See what I write elsewhere first tho.

>  > A) In the future if all desktop apps are restricted, this folder
> will
>  > have to become something more generic that doesn't have anything to do
>  > with downloads. 
>  
>  Are you insane?
>  Generic folders are the bane of anything even resembling security.
>  Being _specific_ is what SELinux is all about. That's what the ENHANCED
>  means, if you strip away all the bullshit bingo words. MAC and RBAC are
>  just the means used. 
... that's a valid point, but how do you suggest interoperability should
be addressed? When I say "generic" I don't mean that it should be used
for everything under the Sun. I mean something that makes sense.
Right now most of the system uses user_home_t anyway - that seems pretty
generic to me.

>  Downloads, especially, deserve to be treated differently, as they
> are
>  data from untrusted sources. 
... all the more reason to put them in their own folder location.

>  > It would become the equivalent of a new /home where you
>  > keep your files. Are there any plans to restrict desktop apps ?
>  
>  Define "restrict". 
I mean make them run in their own domain with minimum priviledge
required to operate, as opposed to running in user_t. I do not 
mean that they should be unable to perform their intended operation.

>  "Mess at will with anything else in $HOME" - why yes,
> absolutely. If my
>  movie player has any reasons reading my mail preferences, I really want
>  to know them. 
Well, as of right now your movie player has the ability to read
user_home_t, as a possible source of movies to play. I can't remember
whether it was mplayer or xine that had the capability to act as a movie
server, but I know one of them did. Now they can transmit .bashrc, and
who knows what over the net. 

Say I rip a bunch of songs with sound-juicer. Now I want to share them
with gift (p2p app). I can't make that work out of the box without
changing the context, because gift can't read user_t files. If the songs
went into a common "content"-style folder, I could make that readable by
gift, mplayer, and whatever needs it, and make them stay away from
user_t.

>  
>  > B) Whatever is decided upon needs to work out of the box. It needs to be
>  > the default way things work, as opposed to me having to jump through
>  > hoops to make SElinux work. Otherwise the average user will just disable
>  > any protection and not look back.
>  
>  There will be hoops. Just like putting on the safety belt when getting
>  into your car is one.
>  
>  I'm sure everyone involved in SELinux development wants to avoid
>  unnecessary hoops. But some will be necessary, just like a firewall,
>  two virus scanners and a yearly reinstall are necessary on today's
>  windos systems. 
I don't think so. The hoops are unnecessary, and the problem can be
solved nicely to fit all people's needs. What you're telling me is that
I shouldn't bother with SElinux anymore -  my main motivation for
playing with this technology at all is that it's applicable to my home
machine - not some ultrasecure server in a basement. I want something 
usable that can improve security at the same time.


>  > This email was titled "Desktop apps interoperability".
> It implies that
>  > we're talking about the average desktop, as opposed to a paranoid
>  > environment. The average person does not know (or care) for evaluating
>  > security requirements and dealing with selinux. He/she wants
>  > transparency, but there's still value in using selinux.
>  
>  The average person also doesn't want their home machine turned into a
>  spammer zombie. At the current growth rate, the average person will
>  soon be faced with a few hard choices. I mean, you can't seriously buy 
>  Windows XP anymore, because you'll be infected with at least one malware
>  before the download of SP2 is finished. The only option is OEM versions
>  that already have at least SP2 applied. 
What's the point that you're trying to make?
If you're implying that security is more important than usability, then
I'm not convinced. 

>  > If you choose to download the content in question, and choose to
> run
>  > mplayer on it, then it seems to me that it should work without messing
>  > with security contexts.
>  
>  Ah, but maybe you don't want mplayer to access everything you
>  downloaded? 
 
That's a tradeoff I'm inclined to accept - especially since mplayer can
stream stuff off the net itself.

>  In the long term, an explicit transfer (a nice GUI tool would make
> it
>  almost painless for the user. In fact, on a drag-and-drop desktop you
>  could probably add it to the drag&drop process) seems to be the better
>  solution. 
How exactly will that work - some details?

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Tom]

On Mon, Mar 28, 2005 at 08:46:24AM -0500, Ivan Gyurdiev wrote:
>  I was suggesting that content should be kept in a sub-folder of
> /home,
>  not that it should be kept somewhere else. I'm sorry for the
>  misunderstanding. I am suggesting that this folder(s) should be
>  standartized somehow. I am saying that settings should be kept separate. 
ah! What you want is /home/tom/.etc/ ?



>  > Generic folders are the bane of anything even resembling
> security.
>  > Being _specific_ is what SELinux is all about. That's what the ENHANCED
>  > means, if you strip away all the bullshit bingo words. MAC and RBAC are
>  > just the means used.
>  
>  ... that's a valid point, but how do you suggest interoperability should
>  be addressed? When I say "generic" I don't mean that it should be used
>  for everything under the Sun. I mean something that makes sense. 
I posted my vision below - an explicit transfer. True, you can still
trick the user, but it stops any automated exploits.


>  > Downloads, especially, deserve to be treated differently, as
> they are
>  > data from untrusted sources.
>  
>  ... all the more reason to put them in their own folder location. 
As I suggested. :)



>  > > It would become the equivalent of a new /home where you
>  > > keep your files. Are there any plans to restrict desktop apps ?
>  > 
>  > Define "restrict".
>  
>  I mean make them run in their own domain with minimum priviledge
>  required to operate, as opposed to running in user_t. I do not 
>  mean that they should be unable to perform their intended operation. 
Then yes, I do believe many programs should be restricted. Anything
with outside contact (web browser, mail reader, etc.) most definitely.


>  Say I rip a bunch of songs with sound-juicer. Now I want to share
> them
>  with gift (p2p app). I can't make that work out of the box without
>  changing the context, because gift can't read user_t files. If the songs
>  went into a common "content"-style folder, I could make that readable by
>  gift, mplayer, and whatever needs it, and make them stay away from
>  user_t. 
I'm still opposed to a generic "content" directory. However, what about
a generic "share" directory with proper auto_trans rules? Anything I
explicitly move there is readable by anything that knows what read()
ist.



>  I don't think so. The hoops are unnecessary, and the problem can
> be
>  solved nicely to fit all people's needs. What you're telling me is that
>  I shouldn't bother with SElinux anymore -  my main motivation for
>  playing with this technology at all is that it's applicable to my home
>  machine - not some ultrasecure server in a basement. I want something 
>  usable that can improve security at the same time. 
SELinux is incredible flexible. It can be configured totally insecure,
if you want. :)



>  > The average person also doesn't want their home machine
> turned into a
>  > spammer zombie. At the current growth rate, the average person will
>  > soon be faced with a few hard choices. I mean, you can't seriously buy 
>  > Windows XP anymore, because you'll be infected with at least one malware
>  > before the download of SP2 is finished. The only option is OEM versions
>  > that already have at least SP2 applied.
>  
>  What's the point that you're trying to make?
>  If you're implying that security is more important than usability, then
>  I'm not convinced.  
I'm implying that jumping through hoops for security reasons is
becoming generally accepted. Most dummy users know that they need a
virus scanner. They have no idea what it is, except that it somehow
protects them from viruses. In fact, most dummy users I've talked to
don't know the difference between a firewall and a virus scanner.
However, they are quite willing to put up with whatever inconvenience
the virus scanner is putting on them, because the point that it's
necessary has been hammered home.

Why should Linux be any different?
"Ok, aunt Ellie, this is a Linux system. It doesn't need a virus
scanner like your windos system did, but [add whatever we finally agree
on as the user-friendly-and-still-safe method]"



>  That's a tradeoff I'm inclined to accept - especially since
> mplayer can
>  stream stuff off the net itself. 
Not if you don't want. That's the beauty of SELinux - I don't care how
many kitchen sinks they've built into their software, on _my_ system it
does what I allow it to do and nothing else.


>  > In the long term, an explicit transfer (a nice GUI tool would
> make it
>  > almost painless for the user. In fact, on a drag-and-drop desktop you
>  > could probably add it to the drag&drop process) seems to be the better
>  > solution.
>  
>  How exactly will that work - some details? 
Aunt Ellie downloads a movie. It goes into the Download folder (or
really anywhere, it doesn't matter much). She drags the movie icon to
the movie player and lets it drop. Movie plays.

Behind the scenes, the file is relabeled or moved into another
directory where mplayer can access it.

Why is this more secure? Because it requires the intervention of a
"trusted 3rd party" (the desktop environment) so you can not force bad
data on my mplayer by compromising Firefox. You can not, for example,
create movie-player-popup ads.



-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom(a)lemuria.org&gt;
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

[Ivan Gyurdiev]

On Mon, 2005-03-28 at 16:09 +0200, Tom wrote:
>  On Mon, Mar 28, 2005 at 08:46:24AM -0500, Ivan Gyurdiev wrote:
>  > I was suggesting that content should be kept in a sub-folder of /home,
>  > not that it should be kept somewhere else. I'm sorry for the
>  > misunderstanding. I am suggesting that this folder(s) should be
>  > standartized somehow. I am saying that settings should be kept separate.
>  
>  ah! What you want is /home/tom/.etc/ ? 
Something like that - yes.


>  Aunt Ellie downloads a movie. It goes into the Download folder (or
>  really anywhere, it doesn't matter much). She drags the movie icon to
>  the movie player and lets it drop. Movie plays.
>  
>  Behind the scenes, the file is relabeled or moved into another
>  directory where mplayer can access it. 
How does this relate to the SElinux work to secure the X server?
Should the desktop environment be trusted?

.. so what you're saying is that nautilus (running as user_t, which has
read access to the file in question, as well as appropriate relabel
access), should determine its mime type, or use the DND target app, and
associate a context with that, which the mime handler can play, then
relabel file to that context (can't copy - what if it's huge?).... and
do this for every mime handler I attempt to open it with?

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Stephen Smalley]

On Mon, 2005-03-28 at 10:05 -0500, Ivan Gyurdiev wrote:
>  .. so what you're saying is that nautilus (running as user_t,
> which has
>  read access to the file in question, as well as appropriate relabel
>  access), should determine its mime type, or use the DND target app, and
>  associate a context with that, which the mime handler can play, then
>  relabel file to that context (can't copy - what if it's huge?).... and
>  do this for every mime handler I attempt to open it with? 
Seems fairly pointless to perform such a relabeling if the context
determination is based entirely on untrusted input from the same source
as the data itself and the user isn't involved to any greater degree
than selecting the file in the first place.  If you are going to run it
through a filtering pipeline (e.g. malicious code checker), then it
makes more sense to set up a relabeling or data copying pipeline using
TE to ensure that each filter stage is unbypassable and tamperproof
(i.e. an assured pipeline in TE parlance).  Note however that relabeling
in place is not necessarily safe, as Linux does not yet fully support
revocation of access.

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Tom]

On Mon, Mar 28, 2005 at 10:12:30AM -0500, Stephen Smalley wrote:
>  Seems fairly pointless to perform such a relabeling if the context
>  determination is based entirely on untrusted input from the same source
>  as the data itself and the user isn't involved to any greater degree
>  than selecting the file in the first place. 
Not so sure about the pointlessness here. The point is that it makes it
more difficult to leverage exploits. Maybe I can break into Firefox,
but with that in place I can't jump from there to mplayer by forcing it
to play something I know will break it.

Lots and lots of system compromises I know about took more than one
exploit and more than one program needed to be broken.


Nevertheless, an explicit "good file" filter is certainly added value.
It doesn't have to be a full-blown virus scanner - on a proper SELinux
system I would expect any unexpected behaviour in mplayer to be
contained. Nevertheless, the filter should at least check whether the
data in question is what it claims to be. No need to port the nightmare
of .doc files that really are .exe or whatever to Linux.



-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom(a)lemuria.org&gt;
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

[Stephen Smalley]

On Mon, 2005-03-28 at 17:47 +0200, Tom wrote:
>  Not so sure about the pointlessness here. The point is that it makes
> it
>  more difficult to leverage exploits. Maybe I can break into Firefox,
>  but with that in place I can't jump from there to mplayer by forcing it
>  to play something I know will break it. 
I'm not sure I understand your intent.  There are two scenarios:
1) mplayer directly launched by firefox.  As the attacker already has
control of the firefox process, the only possible benefit of
compromising a mplayer process launched by firefox is if it has further
permissions needed to achieve his end goal.  And how you prevent such
abuse of a directly launched mplayer is unclear, e.g. do you intend
firefox to engage in an IPC interaction with a process in the desktop
session to ask for the downloaded file to be relabeled prior to
launching mplayer on it?
2) mplayer launched by something other than firefox, e.g. user shell,
nautilus, after prior download of content via firefox.  At this point,
the user has explicitly selected the downloaded file, thus expressing
his intent (modulo any subversion of the user process itself, which is a
separate issue), and can hopefully be trusted not to open files that he
didn't download explicitly (if not, then how can he be trusted to make
decisions about relabeling)?  Hence, in this scenario, the relabeling
doesn't express the user intent any better than the selection by the
user of the downloaded file.  Naturally, what you really want there is a
trusted path mechanism.

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Tom]

On Mon, Mar 28, 2005 at 11:04:26AM -0500, Stephen Smalley wrote:
>  I'm not sure I understand your intent.  There are two scenarios:
>  1) mplayer directly launched by firefox.  As the attacker already has 
[...]
>  2) mplayer launched by something other than firefox, e.g. user shell,
[...]
>  user of the downloaded file.  Naturally, what you really want there
> is a
>  trusted path mechanism. 
Hmm.
I think you are right. I did forget about programs launching other
programs. On the other hand, doesn't that give us another option within
SELinux? Can't we make mplayer-launched-by-firefox run in a different
domain than mplayer-run-by-user? In that domain, it would have access
to the downloaded files, but not to the remainder of the user data.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom(a)lemuria.org&gt;
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

[Stephen Smalley]

On Mon, 2005-03-28 at 18:20 +0200, Tom wrote:
>  I think you are right. I did forget about programs launching other
>  programs. On the other hand, doesn't that give us another option within
>  SELinux? Can't we make mplayer-launched-by-firefox run in a different
>  domain than mplayer-run-by-user? In that domain, it would have access
>  to the downloaded files, but not to the remainder of the user data. 
Yes, that would make sense to me.

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Ivan Gyurdiev]

How about

New Directory Structure (added to /skel, or whatever)
~/content - ROLE_content_t
~/content/desktop - ???
~/content/downloads - ROLE_untrusted_content_t
~/content/media - ROLE_media_content_t
~/content/documents - ROLE_documents_content_t
~/content/mail - ROLE_mail_content_t
~/content/export_web - ROLE_httpd_user_content_t
~/content/export_samba - ROLE_samba_share_t
~/content/export_p2p - ROLE_p2p_share_t

Desktop apps will be restricted to only access the appropriate one.
"Downloading" apps will be restricted to download to
untrusted_content_t. 

Now...how to move things to/from ~/content/downloads in a nice
user-friendly way? What context for desktop? What role will the desktop
play?

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Tom]

On Mon, Mar 28, 2005 at 10:05:58AM -0500, Ivan Gyurdiev wrote:
>  > ah! What you want is /home/tom/.etc/ ?
>  
>  Something like that - yes. 
Ok, that's a good idea.



>  > Behind the scenes, the file is relabeled or moved into another
>  > directory where mplayer can access it.
>  
>  How does this relate to the SElinux work to secure the X server? 
Not at all. X doesn't come in here. There's no reason why I can't do
something similar in non-X environments.


>  Should the desktop environment be trusted? 
Everything is trusted - to a degree. Can I trust my desktop environment
to relabel one filetype to one other filetype? For a military system
the answer would be no, but for a desktop system I think that's a risk
we can take.


>  .. so what you're saying is that nautilus (running as user_t,
> which has
>  read access to the file in question, as well as appropriate relabel
>  access), should determine its mime type, or use the DND target app, and
>  associate a context with that, which the mime handler can play, then
>  relabel file to that context (can't copy - what if it's huge?).... and
>  do this for every mime handler I attempt to open it with? 
You could do priviledge seperation and have a relabeling demon running
in the background.

There's a dozen ways to do it. I really don't care much about which
exactly is used. The point I'm adamant about is two-fold: a) no generic
directories accesable by anyone and their dog - b) explicit transfers
through user interaction are a good idea. Not everything should be
transparent. Firefox's "hey, you downloaded this .exe from the 'net,
you sure you really wanna run it?" is a _good_ idea.



-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom(a)lemuria.org&gt;
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

[Luke Kenneth Casson Leighton]

On Sun, Mar 27, 2005 at 11:57:35PM -0500, Ivan Gyurdiev wrote:

>  There can't be more than one file_type_auto_trans on the same
> folder
>  type (right?).  
 bizarrely, no.

 i believe this issue was raised some months ago, with the
 "alternative file context" thing.

 if file_type_auto_trans also took an executable [domain] as an
 additional argument, i believe you stand a chance of achieving
 what you seek.

 l.

[Stephen Smalley]

On Mon, 2005-03-28 at 11:04 +0100, Luke Kenneth Casson Leighton wrote:
>  On Sun, Mar 27, 2005 at 11:57:35PM -0500, Ivan Gyurdiev wrote:
>  
>  > There can't be more than one file_type_auto_trans on the same folder
>  > type (right?). 
>  
>   bizarrely, no.
>  
>   i believe this issue was raised some months ago, with the
>   "alternative file context" thing.
>  
>   if file_type_auto_trans also took an executable [domain] as an
>   additional argument, i believe you stand a chance of achieving
>   what you seek. 
file_type_auto_trans() is based on the domain of the creating process,
the type of the parent directory, and optionally the class of the new
file.  Hence, you can specify different types on the same "folder" type
as long as the programs run in different domains.  If instead both
programs run in the same domain and are acting on the same directory
type and creating the same class of file, you have to make the program
security-aware if you want to use multiple types on the files (or
similarly, if you have a single program that creates multiple files in
the same directory and you want them to have different types, the
program needs to be security-aware, as with the /etc/passwd
and /etc/shadow type preservation issue).

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Luke Kenneth Casson Leighton]

On Mon, Mar 28, 2005 at 08:36:32AM -0500, Stephen Smalley wrote:
>  On Mon, 2005-03-28 at 11:04 +0100, Luke Kenneth Casson Leighton
> wrote:
>  > On Sun, Mar 27, 2005 at 11:57:35PM -0500, Ivan Gyurdiev wrote:
>  > 
>  > > There can't be more than one file_type_auto_trans on the same folder
>  > > type (right?). 
>  > 
>  >  bizarrely, no.
>  > 
>  >  i believe this issue was raised some months ago, with the
>  >  "alternative file context" thing.
>  > 
>  >  if file_type_auto_trans also took an executable [domain] as an
>  >  additional argument, i believe you stand a chance of achieving
>  >  what you seek.
>  
>  file_type_auto_trans() is based on the domain of the creating process,
>  the type of the parent directory, and optionally the class of the new
>  file.   
 brain-lapse.  of course it is.  duh.

>  [description of how to make programs security-aware] 
 so the issue ivan describes _can_ be solved.

 ... question: in what ways do you ensure that a security-aware
 compromised program is only allowed to create certain filetypes?

 is it to do with using compute_av()?

 l.

[Stephen Smalley]

On Mon, 2005-03-28 at 19:27 +0100, Luke Kenneth Casson Leighton wrote:
>   ... question: in what ways do you ensure that a security-aware
>   compromised program is only allowed to create certain filetypes? 
In the same manner as with a security-unaware program; the domain must
be allowed create permission to the file type via an allow rule.

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Luke Kenneth Casson Leighton]

On Mon, Mar 28, 2005 at 01:23:39PM -0500, Stephen Smalley wrote:
>  On Mon, 2005-03-28 at 19:27 +0100, Luke Kenneth Casson Leighton
> wrote:
>  >  ... question: in what ways do you ensure that a security-aware
>  >  compromised program is only allowed to create certain filetypes?
>  
>  In the same manner as with a security-unaware program; the domain must
>  be allowed create permission to the file type via an allow rule. 
 
 ... there's nothing special needed? ... 
 
 oh - yes, i get it.  create filetype.
 nothing to do with file_type_auto_trans itself.

 l.

[Stephen Smalley]

On Mon, 2005-03-28 at 20:54 +0100, Luke Kenneth Casson Leighton wrote:
>   ... there's nothing special needed? ... 
>   
>   oh - yes, i get it.  create filetype.
>   nothing to do with file_type_auto_trans itself. 
file_type_auto_trans() is a macro that expands to file_type_trans() and
a type_transition rule specifying the default type for the new files.
file_type_trans() is a macro that expands to the set of allow rules
needed for the domain to create the file (including appropriate
permissions to the parent directory as well as to the file).  The allow
rules are always needed for such a file creation to occur.  The
type_transition rule specifies a default in the absence of anything
specified by the program via setfscreatecon(3).  The ability to use
setfscreatecon(3) does require that the domain have one additional
permission, setfscreate, but the permission checks governing the actual
file creation are the same.

This is a general principle in SELinux; the same set of permission
checks are applied for operations regardless of whether the type was
application-specified or a default value, so that you can always
determine what is permissible via the allow rules.  The same is true of
exec transitions for processes.  The set of permission checks doesn't
change; only the types involved change.
 
-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Stephen Smalley]

On Sun, 2005-03-27 at 23:57 -0500, Ivan Gyurdiev wrote:
>  Fundamentally, what I want to know is:
>  
>  1) Do desktop apps need to be confined? Is it a good idea to confine
>  them? 
Yes.

>  2) If so, a shared data type is needed for interoperability. 
>  Is ROLE_home_t acceptable for that purpose. 
A shared data type may be fine, but ROLE_home_t isn't what you want to
use.  And yes, separating settings from data is useful, and yes,
littering user's top-level home directories with application settings
considered harmful. 

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency