Re: Lockdown stuff

[Alexander Larsson <alexl redhat com>]

On Wed, 2003-10-08 at 16:49, Matt Keenan wrote:
> 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...:)

Sure, I'm not saying we can have only 2 levels. But I think we can have
a limited set of high-level policy settings, some really wide
disable-almost-everything setting, and then we need to add some lowlevel
stuff on an as-needed basis.

If you look at some other system that has a billion settings for this
I'm sure you will find that there is a market for applications that
actually help you set the lockdown keys in a way mortals understand.
(I'm told windows has this.) What we want to do is to have out settings
make sense to users (much like the app that sets the settings) instead.
Remember, this is free software, so if someone needs to do some *very*
specific change they can just change the code (or, sometimes just the
glade file, bonoboui file, etc).

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

Yeah, i'm not proposing these two as the only settings. What i'm saying
is that one of these things is probably what the sysadmin wants to do.
If we think of that as our base for what keys are needed I think we'll
do pretty good.
 
> > 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... :)

Sure. But if you're not allowing a user to write files to the primary
user work area then you're probably in the "kiosk" camp, and specific
keys for locking down the desktop aren't needed as much as a
disable-everything-but-this-app key.

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

Yes, and if that menu item is renamed, moved or something the key would
still make sense. And the sysadmin doesn't have to figure out the new
place and set a key to disable it.

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

Yeah, for some special cases like this we might have to add lowlevel
keys. For very seldom used ones there is always the posibility for the
sysadmin to e.g. hack the bonoboui file, or even the code.

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

Sure, in the kiosk mode almost everything is disabled. However, that
doesn't mean we need an on/off switch for almost everything.

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

I understand that. But my idea of good building blocks are slightly
different :)

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

Sure. But do sysadmins want to figure out exactly what files in .gnome2
that need what permissions, or deal with the collisions where some other
app needs to be able to write to .gnome2?

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

This is exactly what i mean.
But, as a starting point, instead of just making up a list, make up 5
different real-life examples of using this. Write down what the sysadmin
would like to achieve, and what would be needed for that. Then take the
5 examples and try to find common policies (or sub-policies) and
lockdown features that are needed.  

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a lonely gay vampire hunter on the run. She's an artistic Buddhist doctor 
on her way to prison for a murder she didn't commit. They fight crime!