Re: Lockdown stuff

[Stephen Browne <Stephen Browne Sun COM>]

Alex,

Thinking about lockdown always makes my head hurt!
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.

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.

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.

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.

> 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?

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


> 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!

> 
> >      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!

> 
> >      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.

> 
> >      - 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?

> 
> >      - 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?

> 
> >      - Disable setting of default printer
> > 
> >      New Key :
> >          /desktop/gnome/lockdown/nautilus/disable_make_default_printer    boolean
> > 
> >      Hides the Make Default Printer context menu item.
> 
> What is this? I don't know of such an item.

This is a sun extension based on the XD2 printers view for nautilus
and should not be part of this dscussion.  
I believe that printers should be locked down elsewhere.

> 
> >      - Restrict user from adding new devices
> > 
> >      New Key :
> >          /desktop/gnome/lockdown/nautilus/disable_new_devices            boolean
> > 
> >      We can't physically stop a user from adding a new device such as a digital
> >      camera etc... but if this key is set, then ensure that Nautilus does not
> >      react to it, e.g. showing an icon for a USB device etc....
> 
> What about "old devices"? I.e. USB device that already plugged
> in/mounted when the user logs in. We could just ignore all mountpoints,
> but then chances are that we'll ignore something we shouldn't, such as a
> /home mount. :)
> 
> Also, given the changes to the volume handling thats been discussed this
> might not really be a nautilus key as such, but more like a HAL or
> gnome-vfs thing.

Agreed

> 
> 
> 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.


> 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?  :)

> 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?

We can leave the special cases to later.

Stephen.


> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc 
>