[Fwd: Lockdown stuff]
Gregory Leblanc <gleblanc <at> linuxweasel.com>
2003-09-18 03:08:58 GMT
Here are some thoughts from one of our favorite gnome panel hackers
about the lockdown stuff that will be worked on in the next GNOME
release cycle. Lots of good ideas, but if there are things missing, now
is certainly the time to bring them up.
Here's what I have on lockdown currently, sort of just a draft quality
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
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
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).
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:
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
(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
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:
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
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.
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.
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.
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 <jirka <at> 5z.com>
A physical understanding is a completely unmathematical, imprecise, and
inexact thing, but absolutely necessary for a physicist.
-- Richard P. Feynman
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org