gnome-user-share (was Re: No more right click terminal)

[Jesse Keating]

On Sun, 2005-07-17 at 14:41 -0400, Colin Walters wrote:
> Longer term though I don't think gnome-user-share is incompatible with
> controlling information flow in a corporate environment.  For example,
> with SELinux you could ensure that every file a software developer
> creates is labeled with a type like developer_home_t or something.  Then
> imagine that incoming WebDAV requests include the security context of
> the invoking process on the remote machine.  gnome-user-share could then
> do access checks versus that context.
> 
> So you as a system administrator could enforce in a *mandatory* way that
> no person logged in as a marketing person (with type marketing_t) could
> access files labeled as developer_home_t, even over the network.
> 
> With trusted computing you can even ensure that a marketing person can't
> subvert the controls by loading a misconfigured or malicious OS that
> would send the wrong security context.
> 
> Things do get more complicated if you want to allow some sharing between
> marketing and development; the real point I'm trying to make is that
> gnome-user-share is just a technology for sharing files and there's no
> fundamental reason it couldn't be enhanced to work better in a managed
> corporate environment as long as it doesn't cost the user experience of
> the other use cases (friends in coffee shops, etc.).

Once all the above is possible, then perhaps it could be looked at.
However SELinux really does get in the way of users doing work right
now.  Yes I know lots of work is being done on SELinux but the sad truth
is that it isn't really usable in a corporate environment with lots of
users (and uses) without having a couple of full time SELinux managers
on staff.  Not very realistic.

> > I'm afraid I lack the knowledge of GConf to understand this statement.
> > Do you mean that it will default to off?
> 
> The default chosen is unrelated to the use of GConf technology; I think
> if it was included in Fedora it would default to on.

This is what I oppose.  Especially if the end user doesn't really know
about it.

> > My users would be fired if they opened up a unauthenticated share in a
> > coffee shop.  Scp, usb fob, https w/ authentication, something along
> > those lines.  Not everybody works in an environment where it is OK if
> > somebody outside the company gets a hold of source code that is being
> > worked on.
> 
> This doesn't make much sense to me; it isn't gnome-user-share's fault if
> a user drops a confidential document in ~/Public any more than it's
> Evolution's fault if they email it to evilcracker at example.com.
>
> If your users have their own laptops that they use for work, I would
> expect to be able to use my own laptop to drop a picture in my ~/Public
> to share with a friend at a coffee shop; I'd expect the company to trust
> me not to do this with confidential data.
> 
> Now if your company owns the laptops you can do what you want, the
> expectation being that users will not do non-work-related things with
> their laptops.  But if you were to turn off gnome-user-share, in
> parallel you should also configure Evolution to not allow sending email
> to non-work addresses with attachments...

Sure we have to trust our users.  However it's a conscious effort to
email code to a person.  It's unconscious to forget that there is
sensitive material sitting in Public from when in the office and when
you open your laptop at a coffee shop, whoops there it is.  Users can
forget easily.  This is why it needs to stay off.  Useful in one context
== extremely dangerous in another.  Unless it can 'sense' contexts and
disable it self when outside a corp network.... no not even then because
IMHO no corp network can be trusted to do unauthenticated shares.
Period.

> > What port then?  Will the system 'automatically' open this port on the
> > user configured firewall, because the system thinks that it should be
> > open (much like cups)?
> 
> I think it's incompatible with the firewall.  Personally I turned off
> the firewall long ago; I don't think it provides much security really.
> That's a whole other flamewar though =)
> 
> (let's please not go there now...)

Sure, but if the user can enable it themselves, I'd like to have a
firewall rule to block it that only root can alter.  Just to protect
users from themselves.  As long as the app doesn't open the firewall for
it, than we're OK on this front.

> > I guess bottom line is that this technology might be useful in some
> > environments.  However it poses a (IMHO severe) security risk in many
> > other environments and I'd like to see Fedora continue the train of
> > thought to turn off potentially security risky services by default and
> > make the user make a conscious decision to turn the service back on. 
> 
> I'd rather make Fedora a usable, general purpose desktop OS by default;
> for managed corporate environments there are always going to be a lot of
> tweaks to make; disabling gnome-user share (or changing its config)
> would just be one more.

I'd rather make Fedora a Linux distribution that is secure by default
and can be expanded to be more insecure and 'easier' to share when
necessary.  Linux was attractive to me and lots of others because of the
idea of security first, and in a lot of cases, security over usability.
Please lets not go into the direction where we have Fedora, and then we
have 400 'tweaks' to get to a 'Secure Fedora'.

> >  I
> > also hope that any UI designed to manage this service requires a root
> > password so that joe user couldn't override an administrative setting to
> > disable this service (especially if it fiddles w/ the firewall once
> > enabled).
> 
> Ugh!  You can tell GConf to have a 'mandatory' flag for a key so that
> user applications aren't supposed to be able to change it (the idea is
> in the UI it would be greyed out); but there's nothing (short of
> SELinux) preventing a compromised or buggy application from ignoring the
> flag and exec()ing gnome-user-share or whatever.

I guess this is a step that must be taken to make Fedora usable in
corporate environments.  I just hate to see the distro take this
direction.  I would also hope that this functionality could be provided
by a package, so that the package could just be excluded from
installation and then there is no possible way for a user to enable it.

> All of our desktop work is predicated on the idea that the user doesn't
> know the root password.  You should never need that to get work done.

But you should know it before being able to start sharing services on
the system.  Of course if there is a firewall set, then the user still
couldn't compile apache in /home/ and start it on a port because the
firewall will block them.

I think we disagree on goals to keep in mind w/ the furtherment of
Fedora.  I think as a sysadmin, you obviously think as a desktop user.
Not that either of these views are wrong, it is just they are different
views and have different goals.  A balance must be found.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating