7:46 a.m.
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>
Cornell University