Re: Lockdown stuff

[Matt Keenan <Matt Keenan sun com>]

Alexander Larsson wrote:


> 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 don't think you can simply refine this down to just two levels or even
3/4/5 levels for that matter... Different sysadmins all require something
different in their setup, so by simply providing them with a very specific
set of lockdown profiles is something that I reckon could be a nightmare
to try and conceive...:)


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

What we are trying to achieve here is the building blocks that will allow
sysadmins to start defining their own lockdown specifics.

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

Agreed taking this to a such a low-grain level is maybe a wrong idea.
And intead of simply defining keys that are specific to menu options then
we should more so think along the lines of as you say later on in your
mail, policies.

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

But giving the user 100% access to their desktop would basically mean that
we should not even be thinking about lockdown at all... let them do as they
wish... :)


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

Fair point..

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

Agreed /desktop/gnome/lockdown/disable_terminal_access would be a better
idea than simply having a GUI based single key per item. But it still
means that basically if set, it would mena hiding the new-termainal menu
item, OK, along with all the other changes required to ensure terminal
access is denied.

The other thing here is that there is bound be numerous places that a policy
key will fall down, where as if the key has a very specific funtion then
it's easy to monitor what is required of that key. Just a slight plus on the
side of having menu specific keys.

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

The approach was more task driven within specific areas of the desktop.
Such as Nautilus/Gnome Panel/Gconf etc...
e.g. I want to restrict a user from renaming icons on the desktop.
So a key to disable the rename menu item was devised. The properties
dosent't just apply to files, but what about the icon properties where
you can use the properties dialog to set a custom icon, change emblem etc.
In a kiosk mode that you mention, allowing one user to change the icon
may result in the next user not knowing where their application is..
And end up calling support and thus wasting time really and costing money.. :)

What we are trying to achieve here is the building blocks that will allow
sysadmins to start defining their own lockdown profiles.


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

The restricting of changing MIME type associations can be done at the OS
level, simply not allowing a user read/write acces to their .gnome2 dir..


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

Sounds like we need to take a step back change the task approach I was
taking which may have been too specific as in per application, and rather
take the view over the entire desktop.

Answer tasks such as :

   - I want to restrict terminal access
   - I want to stop a user from manipulating desktop icons etc...
   - I want to stop a user from adding/removing/changing location of their panel
   - etc...

Anyone want to add to this list...

Matt

--
        __.--'\     \.__./     /'--.__
    _.-'       '.__.'    '.__.'       '-._
  .'       Matt Keenan (mattman)          '.
 /       Sun Microsystems Ireland           \
|                                            |
|   E-Mail : Matt Keenan Sun Com             |
|            mattman iol ie                  |
|                                            |
|  Irish Fantasy League Of American Football |
|           http://www.iflaf.com             |
|                                            |
|        Happy Hookers Golf Society          |
|   http://www.iol.ie/~mattman/golf/hhgs.htm |
|                                            |
|   Phone  : +353 1 8199251, Sun Ext : 19251 |
 \         .---.              .---.         /
  '._    .'     '.''.    .''.'     '.    _.'
     '-./            \  /            \.-'
                      ''