Re: Lockdown... Take 2

[Matt Keenan <Matt Keenan sun com>]

Alexander Larsson wrote:
> On Mon, 2003-10-13 at 16:07, Matt Keenan wrote:
>
> 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.

I'd like to presume that I am also considered smart..etc.. :)
But I too am not overly knowledgable when it comes to lockdown
so if the proposal appears to be "isn't a good proposal", then
we are both in the same boat... can you provide a better 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*).

You want real life examples of requirements of where this proposal can
will be used... I don't have real life examples or manic detailed
research papers that I can divulge to everyone. We are trying to determine
a starting point for locking the desktop in certain areas, I agree the first
proposal I submitted was somewhat cluttered and not convincing, but on
further discussion this is the best that I can come up with WRT to a toplevel
lockdown starting point and a means for making it easier for a sysadmin
whether he/she are trying to lockdown the desktop for a Kiosk setup, hospital
workers, students, web cafe etc.. all of what we've proposed here could
be used in these situations.

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

We want to ensure that a sysadmin defined default set of icons are on the
desktop and that these cannot be changed.

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

You could have various levels of panel lockdown..

panel_lockdown_level = None, Minimum, Normal, Tough, Complete

And that's just 5 possible levels, you could define many levels, and deciding
what goes into each level... ?, really tough to decide, as different aspects
would have different levels of importance depending on the sys admins needs.
So just having one simply level of lockdown seems neater to work with.

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

There is a connection between both terminal and applications launching. If
application launching is not set then terminal access lockdown would reflect
to those options to get terminal acces that are hard coded into the desktop
like "New Terminal" in the nautilus desktop context menu. It would also
attempt to remove panel menu options.

> > - Location Viewing
> >    Locking down of locations a user can browse.
>
>
> Only of filesystem locations I assume? (i.e. not related to web
> browsing.)

Web browsing can be handled by proxy setup which all already have gconf
keys associated for them already.


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

A sysadmin may choose to have a defined set of icons that appear on their users
desktop, these pointing to specific locations or applications that their users
can launch, They do not want users messing with these, so if they are locked
down... their users cannot... Icons that are controlled automatically as you
point out Removeable Media, would simply depend on two things, firstly if the
removable media location was specified in the allowed_locations list then and
Icon could appear for that location, if not then it won't. But if desktop icons
are locked down, the it would appear but it would be locked in place, just like
the other icons, and when the RM was removed the icon would dissappear, the user
would not be specifically able to remove the RM icon.


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

I don't see why not having dirs as part of the list, the only issue is that
with using this approach in limiting menu options appearing, .desktop files
do not contain a full path on Exec line, so just having /usr/bin would not
be useful here in restricting specific binaries from your menus.

> >      This will involve hiding nautilus menu options such as :
> >          Open
> >          Open With
> >          Open In New Window
> >          New Launcher
> >          Scripts
>
>
> Only when necessary I assume.  

Of course... :)

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

Agreed, WRT to other applications needing to follow this but could that not
be done on a gtk basis rather than having to amend individual apps ?
For the moment implementation at the Nautilus level would be a good start.

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

Again as pointed out we are trying to limit the availability of getting
terminal access, not deemed to be a complete secure solution.

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

Reasoning for these was to cater for situations where a desktop is shared
between personal but you don't want users to logout, e.g. in a hospital
situations where nurses share a machine, they don't care about how to log
in etc, they just want to see patients records and stuff so they share a
machine, if the machine gets logged out or screen locked then they would
need to know user/password info...

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

Key writability is key (excuse pun), to everything that we try and implement
with regard to lockdown.

Again

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 |
 \         .---.              .---.         /
  '._    .'     '.''.    .''.'     '.    _.'
     '-./            \  /            \.-'
                      ''