Lockdown stuff

[George <jirka 5z com>]

Here's what I have on lockdown currently, sort of just a draft quality
of course.

Different lockdown goals:

  1) Full lockdown (public access terminal)
  2) Partial lockdown (corporate desktop to ease support, panel locked,
     but user can read write files and all launch apps and change some
     prefs)
  3) Minimal lockdown of certain parameters
     (lockdown of specific config parameters while leaving
      rest relatively free.  Perhaps forcing a panel of
      company 'mandated' launchers, etc...)

Currently we have in 2.4:

  GConf can lock down certain keys.  For lockdown of specific simple settings
  this is fine.  For forcing a specific panel setup it is icky.  Some apps
  still do not check for keys being writable before writing it.  I've fixed
  gnome-panel, gnome-applets, gnome-utils, nautilus, eel and gconf-editor
  to respect key-writability in the UI (make choices not possible if we can't
  do them).

  For most applications this will suffice I believe.  We perhaps need an
  easier tool to work this though.  For the core desktop apps like panel
  and nautilus this only really fits goal #3 above.

  I'm not sure of the control center status, but I think for that what we
  have suffices as long as the UI respects key-writability (which I suppose
  it doesn't currently).

#include <rant-on-how-simple-this-would-have-been-if-we-used-pong.h>

Currently on gnome-panel/gnome-applets HEAD:

  I've done some changes in gnome-panel and gnome-applets to try to implement
  things needed for #1 and #2.  There is a "full lockdown" reminiscent of
  the commie mode.  This is for #1 and some setups in #2.  This setting gets
  propagated to applets which then disable properties.  Basically this means
  that all the UI that allows user to change stuff is not visible.  The key
  for this is currently: 
    /apps/panel/global/locked_down

  For partial lock down, I think it suffices to make it possible to lock down
  a specific panel rather then going down to individual applets.  You can
  do individual applets (especially launchers) with the key-nonwritability
  stuff anyway.  The thing is that I could just HIDE or MOVE the panel with
  the locked applets such that they would in effect be no longer available,
  so I think it kind of defeats the purpose.  On the other hand having a
  whole panel locked down means I could force say a bottom panel with menus
  and launchers set by the admin and disallow the user to change this panel,
  but the user could add a new panel to have some personal setup.  The bottom
  panel would be unmovable and always there so that support could rely on
  having this panel always there for users.  Again all applets and objects
  on this panel act as locked down so you can't change their setup either.
  In effect it's just as locked down as in full lockdown except it's only
  this panel.  The key for that is:
    /apps/panel/profiles/<profile name>/toplevels/<panel name>/locked_down

  Now this solves the "locked down" state for the panel.  But there are
  other things you may need in #1 and sometimes #2.  For one it is the
  inhibition of command line.  So I'm currently using the key
    /desktop/gnome/lockdown/inhibit_command_line
  (the reason for 'inhibit' rather then 'allow' is that just in case the
  schema is not installed or messed up, the user doesn't get a weird setup
  by default.  Like right now there is no schema for this:)
  In this mode all places where the user could enter some command name
  are disabled (and a bit more).  For example you can no longer edit
  launchers obviously since you could change their command.  Some settings
  and UI are disabled which are not necessairly a command line thing
  but related.  For example you can't anymore run procman from the monitor
  applet in this mode (I suppose being able to kill a process then is a
  command line kind of thing).  Perhaps we need more granularity here.
  Another thing is that the device setting in modemlights are disabled,
  though I'm not sure of this, perhaps that's too anal, it won't allow
  dragging launchers from desktop to panel though.

  In any case.  If only the inhibit_command_line key is on, it is
  of course not hard to get around it.  If you can edit/create text files
  you could create a .desktop file and drop it on the panel and then
  run it.  Workarounds there are 1) make sure the user can't do that
  by locking down something in nautilus 2) remove text editor from the
  menu 3) ignore drops of user owned .desktops in this mode.  I've considered
  the third option and I think it is good.  But in any case I'm sure if
  this is the only mode that's turned on, a resourceful user will be
  able to 'run' some binary.  Obviously this is to prevent 99% of the
  users from doing it.  I suppose if you run lots of desktop stations,
  for corporate use, most people will not even try to get around the
  restrictions.  So it's a question of how anal we wish to be, though
  I think that to be perfect it's a little bit of a losing battle.

  The last thing implemented is locking down the ability to "force quit"
  an app.  I suppose some places might want an 'always on' app that can't
  be quit.  If we allow 'force quit' from the panel (or elsewhere) the
  user could just whack it.  I don't think this needs to inhibit the
  metacity 'app is not responding to close, want to whack it' dialog
  since such an app would respond to close by not wanting to close
  and would never be 'non-responsive'.  The key for this currently
  is:
    /desktop/gnome/lockdown/inhibit_force_quit

Onlineness or Offlineness of lockdown:

  Note that all the stuff mentioned above is really not followed 'online'
  that is a key cannot become non-writable online and expect the UI
  to update self accordingly.  Same with the lock down keys noted above.
  Basically after a sysadmin does some changes they must force a restart
  of all sessions.  I think this is reasonable anyway.  It would be
  lots of random code to make this online changable and since such setups
  are usually not tested well, it would be more likely broken anyway.
  So in interest of simplicity and the fact that there is no GUI way
  to implement lockdown, there need not be online changes of such state.

Further work that needs doing:

  Panel:

    Locked out applets.  Basically the id's of the applets that the
    panel should not add or load.  I will work on this next, probably
    a key such as
      /apps/panel/global/disabled_applets

  Nautilus:

    Someone really needs to look at nautilus and lockdown.  I think this
    may be tougher then panel in this respect.  For the #1 scenario I
    think disabeling nautilus is best.  Public access terminal will likely
    want just access to some apps, a web browser and such.  Such terminals
    however usually wipe the home dir after use anyway, so this all
    depends on individual requirements.  Definately any place where
    commands can be run must be protected using the inhibit_command_line,
    and this includes running executables.  Note that this really gets
    weirder with nautilus since you might want to allow some things to
    be run and some not.  Desktop launchers are probably to be
    runnable.  Browsing to /usr/bin likely not.  Also browsing to
    /usr/share/applications and running something not in a menu is
    likely a non-no here as well.  Probably further configuration is
    needed here.  The user could be forced to only his home directory
    and to running only .desktop's and never direct executables.

  Evolution:

    Here probably the "follows writability of keys" is enough.  Though
    obviously inhibiting command line should make it impossible to
    run any executable or script received through email I suppose.

  gnome-terminal (and similar apps):

    I think it should refuse to run a shell if inhibit_command_line
    is on.  This just so that in case the user figures out some way
    to launch it even if it's not in the menus, he doesn't get
    anywhere.  Same goes for things that are really things for
    command line stuff.

  Menus:

    This should be fun.  There are several needs here
      1) Make it possible to make menus read only, basically ignore
      2) different menus per user while taking them all from system
         location (I'm not sure if this is possible, I need to look
         in the current menu spec)
      3) ability to perhaps disable a list of icons.  This would make
         it simple to just disable certain apps without doing much
         voodoo with the menus.  That is, specify a list of .desktops
         that the vfolder code would just ignore then.

  Control Center:

    Needs to follow key-writability in the UI.  I haven't looked at
    this much.  For scenario #1 you'd probably not want this in the
    menu at all.


Phew!  This took me long to write ...

George

-- 
George <jirka 5z com>
   A physical understanding is a completely unmathematical, imprecise, and
   inexact thing, but absolutely necessary for a physicist.
                       -- Richard P. Feynman