Re: Lockdown stuff

[Malcolm Tredinnick <malcolm commsecure com au>]

On Wed, 2003-10-08 at 00:49, Matt Keenan wrote:
> As a follow up to what George has been working on, I want to get this
> discussion going again. I have been looking into further locking down the
> desktop in various areas, my approach was to take a list of tasks that I would
> like to achieve and see what could be done within Gconf that would enable us to
> acheive these tasks.

Sounds like a reasonable way to start things off. A few comments on
initial reading...

[...]
> 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
> 
>      If lockdown_desktop_icons is set then basically all default icons on
>      the desktop are locked down, a user cannot remove/rename/move them and
>      they cannot add more icons.
> 
>      Basically involves hiding the menu items Rename, Move To Thrash, Move to
>      Thrash. And for adding new items, restrict dropping, and the menu items
>      New Folder/New Launcher from within Nautilus.
> 
>      If lockdown_desktop icons is not set then the icons_to_lockdown key is
>      referred to, this key will contain a list of specific .desktop files that
>      are locked down, and only these will be restricted from removing/renaming/
>      moving. A user will be able to add new icons, and the newly added ones
>      will not be locked down.
> 
>      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.
> 
>      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.
> 
> 
>      - 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.
> 
> 
>      - 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.

My first thought was that this was possibly too fine-grained, or at
least not an independent set. If your goal is to completely stop people
launching a terminal, say, then you need more than this (e.g.
disable_terminal must imply disable_scripts is also set and there's now
way I can be allowed to open up an editor, since it's pretty easy to
launch a terminal from many of those). If the goal is just to make it
difficult to launch a terminal or run scripts, do you really need to go
into this much detail?

I have spent too long in both university and corporate environments
where there were inconsistent restrictions similar to this to think that
it isn't going to be an issue.

Consequently, can some of these be coalesced? For example,
"no_messing_with_background" instead of the last two,
"no_messing_with_files" instead of cut, copy, paste, duplicate, link,
etc. OK, my key names are less professional than yours, but I only do
this for a hobby.

I would have a similar question about some of the other options. It just
feels a bit too fine-grained. On the other hand, as soon as we start
making generalisations or assumption, we'll discover that we don't
understand peoples' darkest desires and they really want to turn off
"duplicate" but allow "cut", "copy" and "paste".

Since this is deep admin voodoo, I agree that the "just pick one option"
approach is inappropriate.

[...]
> 3. Network Access
> 
>      - Restrict user from setting/changing their proxy settings
> 
>      There are already a number of keys for this in gconf for http, ftp etc.
>      Just missing two for gopher. So two new keys needed here
> 
>          /system/proxy/gopher_port      int
>          /system/proxy/gopher_host      string

There are more than three people still using gopher? Wow. (Man, I'm
going to get flamed for that.) :-)

There is a slippery slope problem here, though: it's pretty easy to come
up with extra protocols (internet telephony, etc). Where do we stop? I
have no answer to this, just raising the issue.

>      - Define a list of http locations that proxy is not needed for.
> 
>      New Key :
>          /system/http_proxy/no_proxy_for      list/string

This already exists in GNOME 2.4. The relevant key is
/system/http_proxy/ignore_hosts (it is a list). The GUI to set it is a
GNOME 2.6 item.

> 4. GConf
> 
>      - Restrict users from accessing gconf database.
> 
>      New Keys :
>          /desktop/gnome/lockdown/gconf/disable_gconf_tools_access    boolean
> 
>      If set then the user cannot run gconf-editor or gconftool-2.

How do you see this working? You cannot cripple gconftool-2, since I
could just use a different version (if I'm Evil User). So somehow you
need to have gconfd know that only some things can change the database.
But some users will be allowed to change the database, so how will
gconfd know that?

This feels like the wrong approach. Isn't this exactly what the
/etc/gconf/2/path file is meant to control. Settings that are not meant
to be changed are put in a readonly file that is mentioned last in the
path file. You can even remove $HOME/.gconf2/ from that file. All your
other gconf comments look like they can already be handled by 'path' as
well.

The only problem I can see is that that file is global, not per-user.
But I can sort of see that if I was running a computer lab, then the
different GConf policies would be enforced by having different prefixes
from which to run GConf (and hence different ${prefix}/etc/gconf/2/path
files).

[...]

> Phew... now that took a bit of time..

Still, it's nice that you took the time to do it. There is something
concrete to work with. :-)

Cheers,
Malcolm