Desktop apps interoperability

[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 at cornell.edu>
Cornell University