Re: Lockdown stuff

[Alexander Larsson <alexl redhat com>]

On Wed, 2003-10-08 at 11:50, Stephen Browne wrote:
> Alex,
> 
> Thinking about lockdown always makes my head hurt!

Its not gonna be better if every single user of lockdown has to think
about it.

> Your point about talking to customers/sysadmins and asking them 
> what they want is a good one and somethinig we have already done 
> to some extent.

Care to share some of the results? For instance, for every key proposed
I'd like to know what type of lockdown it could be used to implement and
how many were interested in that type of lockdown.

> The problem is coming up with a one size fits all solution.
> How granular should the connfiguration of lock down be?
> Do you want to lock down for security reasons or just to make it
> harder for your users to make changes to your default setup that may
> result in more service calls?
> Do you want to be able to lockdown all things via gconf (centrally)
> or are you prepared to write scripts/fiddle with permissions/etc
> etc etc.
>
> I think maybe we need to concentrate on a subset of Matt's propopsal
> or a subset of his proposed keys.   Each key we agree on and get 
> implemented gets us one step closer to a complete solution.

To be able to agree on any key at all I need to know what types of
lockdown we're aiming for so i can judge wether the keys introduced:
a) helps implementing such a lockdown
b) are on the right level

> I think we should also firstly concentrate on the sysadmin case where
> the goal of locking down the desktop is not for security reasons but
> simply to reduce the number of service calls he has to respond to.
> This is a common case for enterprise desktop sysadmins.
> Perhaps this along with some documentation on how to lock things down
> with ACLs / permissions / other securty config could provide a solution
> to those who want to lock down for security reasons. People who run
> kiosks for example.

Basically I can only see two basic kinds of lockdown that I think will
be popular:
a) kiosk mode - Let the user browse the web and/or perhaps run some
specific 3rd party app
 In this mode I think you just want to disable most of nautilus, you
also want to limit the panel so you can't change anything or launch
anything.
b) "limit users" style of lockdown, where all configuration is limited,
and where you don't expose the whole filesystem to the user. (This is
what you describe above.)
 In this mode i can see limiting file changes to a certain subset of 
locations could make sense. So would not letting you start any random
executable. 


Kiosk mode seems the easiest, as I think most users of it would want
exactly the same thing (limit everything but some app). The limited user
mode is a bit harder, since it can't really be an on/off toggle.
Sysadmins will want to do it in slighly different ways. Perhaps someone
could write up a set of different examples of sane setups for these
kinds of lockdown. Then we could go from that to what features would
need to be implemented. Just adding a key for every menu item in
nautilus isn't right.

> Let me try to answer some of your questions below:
> 
> On Wed, 2003-10-08 at 09:31, Alexander Larsson wrote:
> > On Tue, 2003-10-07 at 16:49, Matt Keenan wrote:
> > 
> > > I have split the tasks into sections :
> > 
> > I'll comment on the Nautilus details first, then I have some general
> > comments at the end.
> > 
> > > 1. Nautilus
> > >      - Restrict a user from removing/adding/moving/renaming or accessing the
> > >        properties of desktop icons.
> > > 
> > >      New keys :
> > > 	
> > >          /desktop/gnome/lockdown/nautilus/lockdown_desktop_icons    boolean
> > >          /desktop/gnome/lockdown/nautilus/icons_to_lockdown         list/string
> > > 
> > 
> > When you say "desktop icons" what do you mean? All files in the desktop
> > directory? Or just the home/trash/volume icons? You talk about folders
> > and stuff as if you mean all files, but then you say "contain a list of
> > specific .desktop files", and the desktop is not only about .desktop
> > files. (Also, note that the trash/home/volume icons are not .desktop
> > files any more, but special in-memory objects.)
> 
> This would be for all desktop objects I would think (including desklets 
> I suppose)  Can we deal with the more global key first and see if we
> agree that it makes sense?  The list key was an idea to provide some 
> granularity to this lockdown by being able to specify a set of objects
> which could not be manipulated.  Perhaps this is an unrealistic goal at 
> this stage.

The reason I asked this is because the thinking behind this part seems
to be totally contrary with how we want the Desktop to be used. The idea
seems to be that the desktop is just a place where there are a few
launchers. This thinking makes the desktop a worthless thing full of
launchers like the windows one. 

What we want is to make the desktop the primary work area for users
files (although perhaps not the primary storage area, thats still in
debate). Our goal is for the desktop to be as natural to use for this as
for instance the MacOS 9 desktop. This means that the desktop is
absoulutely 100% user controlled. Its an area that the user can be
guaranteed that he can do whatever he wants with, and this shouldn't
lead to any problems. Can you imagine disabling writing to the desktop
on MacOS 9? 
 
> > Also, is this meant to be a serious lockdown, or just a simple thing
> > that you can work around easily? I mean, browsing to ~/Desktop in a
> > nautilus window will allow you to do many things to the desktop, as will
> > opening up any application and saving things in ~/Desktop.
> 
> This is my question from above, security or reduced service calls?
> Mostly enterprises just don't want their users to be able to 
> (or accidentally) delete the icon for a particular app launcher they
> put into their default configuration.  (this spawned the list idea)
> 
> You could restrict users from going to the ~/Desktop dir in nautilus
> (apart from the desktop view of course) with a restrict_locations key?

This shows exactly why this type of lockdown keys are hard to use. In
order to actually use them you have to think about everything the user
can do and modify all sorts of keys in order to implement a policy. This
makes them much much harder to use than policy-based keys.

> Of course you could just make ~/Desktop unwritable via permissions :)

Yup. We shouldn't forget what the rest of the system allows you to do.

> > Also, even for the lame lockdown you need to handle things like paste,
> > and various other global keybindings.
> 
> Yep those things would have to be handled in the implementation.
> Testing an implementation will surely show up 6 miillion other ways to
> do things that we didn't think of. :/ and probably miss lots of others!

Yes, but if they keys were policy-based, i.e.
dont-let-user-start-terminal vs
desktop_context_menu_new_terminal_disable, this is much easier to think
through and fix once (or in an update) than if each sysadmin needs to
find all the ui functions you have to disable.

> > >      The above two keys will also be used to determine if an icons properties
> > >      can be accessed.
> > > 
> > >      - Restrict users from accessing a files properties, either from File menu or
> > >        context menu.
> > 
> > What is this meant to do? You can still see most of a files properties
> > in e.g. the list view or by changing the icon captions.
> 
> Good point!

The property dialog just shows the properties of a file, something which
is one of the main reasons to use a file manager. I can't really think
of any sane reason to disable it. That its in the proposal just seem to
say to me that the list of keys was made up by looking for things that
can be disabled rather than what people need.
 
> > >      New key :
> > >          /desktop/gnome/lockdown/nautilus/disable_properties     boolean
> > > 
> > >      If set simply hide the properties menu item.
> > > 
> > > 	
> > >      - Restrict users from running applications within nautilus.
> > > 
> > >      New keys :
> > > 	/desktop/gnome/lockdown/nautilus/disable_application_launching  boolean
> > > 
> > >      This will have the affect of hiding the Open, Open With and Open in New
> > >      Window menu items, and also disable double-click launching.
> > 
> > This means you can't use Nautilus to open any file. Why would you even
> > use nautilus if you couldn't do that? Maybe you could still use it to
> > copy/move/rename files, but restrictions configured that way makes no
> > sense to me at all.
> 
> Does this make more sense if I said this would only be for executables?
> This would mean I can still open gedit for my text file, but I can't run
> that odd little program (delete_all_my_files.sh) that I just downloaded
> from the web.
> 
> Yes I can just run it from the commandline but I am an ex windows user
> and dont know what a terminal is :)
> 
> Again we are trying to reduce service calls by reducing the ways a user
> can be destructive (on purpose or not) using the GNOME environment.

So, a policy key like "don't allow user to run non-system executables"
sounds much better to me. This means users can actually use the file
manager for their file (i.e. double clicking on the letter they are
working on to open it in OOo). It also means that this key can be used
in other places that control similar things. For instance, if this key
is true users shouldn't be able to change their mime data so that some
filetype is opened by a random delete_all_my_files.sh app.
 
> > >      - Restrict a user from browsing directories/locations.
> > > 
> > >      New Keys :
> > >          /desktop/gnome/lockdown/nautilus/restrict_viewable_locations    boolean
> > >          /desktop/gnome/lockdown/nautilus/viewable_locations         list/string
> > > 
> > >      If restrict_viewable_locations is NOT set, then all locations/directories
> > >      are viewable to the user. If it is set then the viewable_locations key will
> > >      be checked. This key will contain a list of locations that a user can view
> > >      which can include directory paths and nautilus locations such as network://
> > >      etc.. If the list is empty then the user cannot view any locations.
> > 
> > What about subdirectories? if $home is listed, can you view
> > $home/subdir?
> 
> yes but perhaps we need two list keys combined so that I can allow $HOME
> but restrict $HOME/Desktop?

You're example is very bad in my opinion ($home contains
non-user-controlled vital data such as config files, while $home/Desktop
is user owned and safe), but you could have both an allow list and a
deny list. Of course, with all sorts of recursive options (e.g. can view
subdirs of this dir) things become exploitable using symlinks.

> > >      - Define sensitivity for all context menu items :
> > > 
> > >      New Keys :
> > > 
> > >          /desktop/gnome/lockdown/nautilus/disable_new_window              boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_new_folder              boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_new_launcher            boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_new_terminal            boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_scripts                 boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_cut                     boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_copy                    boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_paste                   boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_duplicate               boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_make_link               boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_rename                  boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_move_to_thrash          boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_stretch_icon            boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_restore_icon            boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_add_to_archive          boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_disks                   boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_use_default_background  boolean
> > >          /desktop/gnome/lockdown/nautilus/disable_change_desktop_background
> > >                                                                           boolean
> > > 
> > >      Just hide the relevant menu item of the key is set.
> > 
> > This is totally tied to the current UI. In fact its totally tied to
> > yesterdays UI as the menu is different now. It makes no sense to have
> > such a finegrained setup, and its gonna be a total pain both for users
> > and developers to keep it synchronized with changes to the UI.
> 
> Absolutely valid point!  How do we go about locking down some/all of
> this functionality do you reckon?

You'd start with looking at the list of examples i talked about above,
then you figure out what types of features need to be possible to
disable, resulting in a set of lockdown policies. Then mapping these
policies to actual functionallity in the apps shouldn't be that hard.
  
> > In general, I think your proposal is way too fine grained. A sysadmin
> > that wants to lock down a box for some specific usage has to do a *lot*
> > of work figuring out which of the lockdown keys to enable, and chances
> > are high that he didn't think of some way to work around the
> > configuration, making the box not locked down. 
> 
> I think you are right here. Someone who wants to lockdown so tightly
> or specifically may (have to) find other ways of doing it.

I doubt there are many who wants that anyway.

> > Some of the keys you proposed can be configured in such a way that they
> > make zero sense (allow cut+paste, but not copy?), and some things are
> > better locked down in other ways (such as filesystem permissions). Many
> > of the keys are such that any working/useful configuration of them make
> > nautilus pretty much useless, and a better way to do the lockdown would
> > probably be to disable nautilus. 
> 
> Maybe we need a key for that?  :)

Sure. I think a kiosk style total lockdown key should disable most of
nautilus.

> > I think a better approach to the lockdown problem is to sit down and
> > talk to people who want to use lockdown and see what they really want to
> > accomplish, then sit down and figure out a few higher-level lockdown
> > operations that we implement throughout the desktop and that allows all
> > the interesting policies to be implemented. This will allow mortal
> > sysadmins to figure out how to set this up, and it will probably make
> > the lockdown mode work better since the people who know the software
> > best (the developers) will pick the feature details for a particular
> > lockdown policy. It will also make the lockdown keys work across
> > upgrades in a way that lowlevel 'disable-this-menu-item' keys won't. We
> > probably won't be able to make a few high level policy settings do
> > everything, so we might need to add a few lowlevel keys for those
> > special-case situations where we can't get a sane highlevel policy that
> > works for everyone.
> 
> Right so for nautilus as a start can we agree on some (any) keys we 
> should implement?

I'd like to see a bit more reasoning about the keys first. I'm not just
gonna say "/desktop/gnome/lockdown/nautilus/disable_restore_icon sounds
ok to me". I want to know what the keys are good for, who wants them,
how they interact with other proposed keys, and I much prefer policy
keys over disable-ui-element keys.
                  
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a suave sweet-toothed sorceror with a robot buddy named Sparky. She's a 
violent Buddhist advertising executive prone to fits of savage, blood-crazed 
rage. They fight crime!