Re: Lockdown stuff

[Jonathan Blandford <jrb redhat com>]

George <jirka 5z com> writes:

[ Sorry for the delay in replying.  I've been on vacation for a week and
  didn't get much of a chance to reply to mail until returning.  I am a
  little disturbed to see giant threads on spatial file managers and none
  on this issue, though.  ]

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

It's a nice summary, and good starting place for the discussion.

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

Small, medium and large; sounds good.  The only thing I'd add to it is
that GNOME doesn't necessarily have to do everything.  We can use acl's
to prevent people from running programs, and in general lock down the
box beyond GNOME's ability to.  I think for full lockdown (Case 1), we
should work with that.  It will make our life much easier, anyway.

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

It should be relatively easy to get this going.  I meant to do this for
2.4 but it slipped through the feature freeze.

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

Rather than just #including a rant, lets talk about reviving either the
pong code base or it's functionality.  I know we've had this talk on irc
before, but the GConf <-> GTK+ mapping is done too many times to let
people keep reinventing it.  We need to have a solution for this in the
supported platform.

So, George, what do you think about pong's current state?  Does it make
sense to port it to GTK+ 2.0 and try to get it into the platform?  I'm
not super thrilled with GConfPropertyEditor in the control-center, and
would switch to something better.

>   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

What's the difference between an applet being locked down and all it's
keys non-writable?

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

As an alternative key name, how about 'disable_command_line'.  'inhibit'
is a little weird to me.  Also, what exactly do you mean by
command_line?  Perhaps we should have a few more keys here to be more
explicit.  Do we want to avoid running of arbitrary binaries?  Permit
only launchers that we allow?  Perhaps thinking a bit of the actions
that we need to control would be good.  For comparison, here's what KDE
does here:

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdecore/README.kiosk?rev=HEAD

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

To be perfect, we'll probably have to count on the system to help out.

>   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

I don't like this option, anyway.  We should make it always on.  (=

[ Same comment above about 'inhibit' applies here, too ]

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

We have other configuration options that are per-session.  Most notable
are a11y and language.  I don't think this is a problem at all, but
requires proper documentation in the sysadmin guide.

> Further work that needs doing:

<snip various apps>

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

Should be easy to do.  The only problematic thing here is that sometimes
a given setting is compromised of a set of keys.  The big examples here
that I can think of are the theme manager and the background dialog.  In
addition, we should probably disable the whole dialog somehow if you
can't write to any of the keys.  That fits more into the menu discussion
though.

Thanks,
 -Jonathan