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. Greg
--- Begin Message ---
- From: George <jirka 5z com>
- To: desktop-devel-list gnome org
- Subject: Lockdown stuff
- Date: Wed, 17 Sep 2003 12:30:29 -0700
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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list gnome org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
--- End Message ---
Attachment:
signature.asc
Description: This is a digitally signed message part