Re: Lockdown... Take 2

[Alexander Larsson <alexl redhat com>]

On Mon, 2003-10-13 at 16:07, Matt Keenan wrote:
> Folks,
> 
> OK after much taught based on the feedback given to my first proposal I have
> gone back and taken a much higher approach to the problem in hand.

I don't want to come off all negative, so I start by saying I think this
proposal feels a lot better than the last one. I'll put some detailed
comments in the proposal below.

However, it still doesn't contain what I want in the areas of background
research and rationalization. There just isn't any way for me as the
maintainer to decide whether this is the right approach or not, and
whether these keys are at the right level, control the right things,
interact in the best ways, etc.

For instance, anyone could offer me a proposal like:

--- stupid proposal ---

Areas that need to be locked down:

- User interface colors
 Sys admins want to control what colors are on the screen

- Widget control
  Locking down some aspects of widgets

keys:

 /desktop/gnome/lockdown/disable_red
   Don't ever use the color red in the user interface
 
 /desktop/gnome/lockdown/disable_menu_popup
   Don't let the user pop up any menus

--- end of stupid proposal ---

Now, how can I determine if this is a good proposal? I'm not stupid, so
I can tell this isn't a good proposal, but if it was more serious I'd
have a pretty hard time telling, because I don't have enought experience
in lockdown use. So, consider me a smart but not very knowledgable
person (when it comes to lockdown) that you have to convice that your
proposal is a good one.

The set of keys is basically an API, but targeted towards system
administrators. When you design an API you typically start with some
research about the requirements of the API. Then you sit down to think
and discuss for a while, comming up with an API proposal. Then you need
to go back to the requirements and see if the API proposal does in fact
fulfil the requirements.

Now, you probably did all sorts of research and thinking about
requirements and possible reasons for needing various types of lockdown.
But you didn't show anyone else this, so its really hard to judge what
you proposed. What I'd like you to do is make up a set of examples from
real-life situations, say things like: web-kiosk, university with
students and teachers, data entry or call center workers, company with
desktop for secretaries, etc. Just make up the situation and goals of
the lockdown, and then say what type of lockdown the sysadmins would use
in this situation to achieve the goals. Select examples that you think
are common and such that we cover as much of the lockdown usage as
possible.

Post these examples so that everyone can have them as a base for
evaluating and discussing various lockdown proposals. Then you (and
others) can use these examples to see what features are required and
work out what set of policies and lowlevel keys are wanted/needed.

Then when you propose the "disable_red" key you can refer to the
examples to see exactly why it is important to control the colors on the
desktop and that "disable_red" is the right level since "use_gray_scale"
just wouldn't be flexible enough even for the example usages (which
everyone agrees are sane). Its also possible to see whether a key really
makes sense on its own, or if its always used with another key in real
life situations. That might mean they should/can be combined (although
of course we shouldn't always combine things just because they *can*).

> By simply looking at the general areas that need to be locked down such as :
> 
> - Desktop Icons
>     Sys admins want to lockdown a users icons.

What different reasons is there for wanting to do this? How does these
different reasons affect how you want to control the desktop icon
lockdown? Do we want to disallow use of the desktop as the primary work
area, or do we just want to make sure some set of launchers are always
on the desktop?

> - Panel Configuration
>     Locking down of panels location, contents etc..

Do we always want to lock it down completely, or do we want perhaps have
a set of panels and applets/launchers locked down, but allow the user to
add additional panels/launchers/applets?

> - Application Launching
>     Locking down of what applications a user can run.
> 
> - Terminal Access
>     Locking down of terminal access.

How does this relate to application launching? For instance, if
application launching is not locked down, its pretty easy to get a
terminal. Is this a problem, or is terminal access lockdown supposed to
be just a feelgood/minimize ui confusion lockdown (if not combined with
other forms of lockdown)?

> - Location Viewing
>     Locking down of locations a user can browse.

Only of filesystem locations I assume? (i.e. not related to web
browsing.)

> - Lock Screen / Logout
>     Locking down of Lock Scree and Logout functionality.
> 
> The origional idea as too grunular in that I was focusing on tasks within
> areas of the desktop such as nautilus only or the panel only.
> This approach concentrates on the desktop as a whole.
> 
> Now for the details :
> 
> I still propose that we use one specific location within Gconf for holding
> lockdown keys :
> 
>       /desktop/gnome/lockdown
> 
> 
> - Desktop Icons
> 
>       A new key will be used to lockdown desktop icons :
> 
>       boolean         /desktop/gnome/lockdown/lockdown_desktop_icons

I'm still not sure what the purpose of this key is. Do you want to have
nothing on the desktop but the initial launchers, or do you want to make
sure some icons are not removed? Personally I guess that both would be
useful. Also, what about icons that are controlled automatically, such
as removable media?

>       If this key is set then icons on the desktop are completely
>       locked down, you cannot :
>           Remove
>               Hide Move To Thrash menu item.

Also needs to trap global key bindings.

>           Add
>               Hide New Folder and New Launcher menu items.
> 
>           Rename
>               Hide Rename menu item.
> 
>           Placement
>               Ensure icons cannot be dragged
> 
>           Properties
>               Icons properties is not accessable, so that
>               users cannot change to a custom icon or add
>               emblems. Hide Properties menu item for icons.

Hiding the properties menu item doesn't seem right to me. We should just
disable changing of any properties for locked down files.

>           New Folder
>               Hide New Folder menu item.
> 
>           Duplicate
>               Hide Duplicate menu item.
> 
>           Stretch/Restore
>               Hide Stretch/Restore icon menu items.

What about "clean up by name"? Also, totally locking down icon placement
like this makes "Keep Aligned" not very useful, so that would have to go
too.

Things that default to e.g. downloading to the desktop would also have
to respect this setting. So would the file selector (the new one will
probably have a shortcut to the desktop).

And we'll have to notice that this is still just a feelgood lockdown
key. Its really easy to change stuff in ~/Desktop using other apps.

> - Application Launching
> 
>       Two new keys will be used for the lockdown of application launching :
> 
>       boolean         /desktop/gnome/lockdown/restrict_application_launching
>       string/list     /desktop/gnome/lockdown/allowed_applications
> 
>       If restrict_application_launching is set, the the list key
>       allowed_applications will be checked. This list will simply be a list
>       of binaries that are allowed to be launched. By default the key
>       restrict_application_launching will be FALSE, and the list key
>       restrict_application_launching will be FALSE, and the list key
>       allowed_applications will contain a complete list of applications are
>       available on the desktop. This will ensure that when application
>       restriction is turned on a sysadmin will be able to simply remove
>       whatever applications are necessary from the list.

While this is good for many setups I think for some setups it would be
quite a lot of work to setup. If you could additionally define
directories with binaries that would probably help. (you could add
/usr/bin if you just wanted the user to not be able to launch unknown
apps.)

>       This will involve hiding nautilus menu options such as :
>           Open
>           Open With
>           Open In New Window
>           New Launcher
>           Scripts

Only when necessary I assume.  

>       This will also control double-click behaviour on executable permission files.
> 
>       Within the panel this list can be used to determine what menu items are
>       displayed. The Exec element of a .desktop does not appear in the allowed
>       applications list then that menu item will not be displayed in the Menu.
>       For example if you wanted to get rid of the Find Files menu item then simply
>       turn on restrict_application_launching and make sure gnome-search-tool is
>       not in the allowed_applications list.
> 
> - Location Restriction
> 
>       Two new keys will be used for the lockdown of locations within nautilus :
> 
>       boolean         /desktop/gnome/lockdown/restrict_locations
>       string/list     /desktop/gnome/lockdown/allowed_locations
> 
>       If restrict_locations is not set, then all locations will be viewable
>       however if it is set, then the list contained in allowed_locations will
>       be checked to see if a user can browse to that location within nautilus.
>       If the location is a path, then any subdirectories underneath that path
>       are seen as accessable locations. Location restriction can also be used
>       for hiding the Disks menu item. The adding of new devices can also be
>       dealt with here, as the new devices location will not be in the allowed
>       locations list, so therefore will not appear within Nautilus. By default
>       location restriction will be FALSE, and the list allowed_locations will
>       contain a default list of viewable locations from nautilus.

There is a problem with specifying some types of locations though. For
instance things in the users homedir. The homedir can be mounted on
different places on different machines, and the username is different. I
guess we would have to allow/expand ~/ in the list.

Also, not only nautilus would have to follow this, but e.g. the
fileselector and other apps that let you browse the filesystem.

> - Command Line Interface
> 
>       A new key will be used to control whether a command line interface
>       will be available or not.
> 
>       boolean         /desktop/gnome/lockdown/disable_command_line
> 
>       This key if set will be responsible for hiding all terminal access from
>       users. Hiding such menu options as :
> 
>           New Terminal
>           Run Application
>           Command Line applet.
>           Applications->System Tools->Terminal
> 
>       Although if you want to restrict specific terminal items appear in the
>       panel menus you could just ensure that gnome-terminal does not appear
>       in the allowed applications list.

The ambitious hacker will find a way to open a terminal anyway (unless
other lockdown keys limit things to much), but this is probably enough
for most people. 

> - Panel Configuration
> 
>       A new key will be used to lockdown the panel :
> 
>       boolean         /desktop/gnome/lockdown/lockdown_panel_config
> 
>       This key if set will control the appearance of the following
>       menu items :
>           Add To Panel
>           Delete This Panel
>           Properties
>           New Panel
> 
>       Individual menu items on applets and launchers can also be controlled
>       such as Move, Lock and Remove From Panel.
> 
>       This can be used to ensure users cannot Add new panels, remove existing
>       ones, change the contents of existing panels, or change the location of
>       existing panels by monitoring drag and drop of panels.
> 
> - Lock Screen/Logout
> 
>       A new gconf key will be used to determine wheter the lockscreen and
>       logout menu options appear in the panel :
> 
>       boolean         /desktop/gnome/lockdown/disable_lockscreen_and_logout
> 
>       This is particularly useful in Shared Desktop scenarios where you
>       specifically do not want users to lock their screen or logout.

Combining these into one when we can't even come up with a better name
for the result than foo_and_bar is probably not right. Additionally you
might want to limit access to restart and shutdown in the panel/gdm, but
still allow you to log out.

> - Miscellaneous
> 
>       o Desktop Identity
>       The desktop background and themes already have gconf keys associated
>       with them. The writability of these keys can be checked and if
>       not writable, then in nautilus the Change Desktop Background and
>       Use Default Background menu items can be hidden and in the Panel
>       the Theme Manager menu item can be hidden. The Theme Manager could
>       also be hidden of Application Launching restriction is used and the
>       the binary gnome-theme-manager is not present it will not be displayed.
> 
> 
>       o Setting Printers.
>       To ensure a user does not change their default printer etc, then the
>       printers:// location can be ommited from the allowed locations list.

printers:// is a ximian-only location, and is probably not the only way
to configure printers, but the other lockdown keys are probably enought
to limit printer configuration anyway.

>       o MIME Type Setting
>       The application gnome-file-types-properties is used to change your
>       default MIME type settings. To restrict a user from doing so then
>       remove this binary from the allowed_applications list.

Of more interest would probably be to limit the apps you can chose as
handler for mimetypes. But this could be handled with something like
allowed_applications too.

>       o Default Keyboard Shortcuts
>       Similar to MIME settings to change your default keyboard and shortuts
>       the binary gnome-keybindings-properties is used. Just ensure this
>       not be shown for them. This could also be done for Multimedia Keyboard
>       shortcuts.

Of course, you can set these with gconf-editor too. Probably a better
way of handling this would be using gconf key writability.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a world-famous Jewish shaman in a wheelchair. She's a supernatural 
thirtysomething queen of the dead with a flame-thrower. They fight crime!