-----Original Message----- From: Chris Howells [SMTP:chrish@gmx.co.uk] Sent: Monday, December 03, 2001 1:25 PM To: suse-linux-uk-schools@suse.com Subject: Re: [suse-linux-uk-schools] Hi all
May I ask what kind of work? What I'd really love is for somebody to make it possible to restrict the things that are possible in KDE -- for example so that a school could use it on the desktop without the kids fiddling with all the settings.
I did notice however something that Waldo put on:
http://developer.kde.org/development-versions/kde-3.0-release-plan.html
about preventing users changing the wallpaper, and stuff. [Simon Wood]
Can't this be done by sym-linking the appropriate parts of '.kde' to a non writable master copy. I though I'd limit my users (my wife) in this fashion but see told me not to.... You could also limit access to the config application. Ah the power of the UID.... Simon W.
-----Original Message----- From: Chris Howells [SMTP:chrish@gmx.co.uk] Sent: Monday, December 03, 2001 1:25 PM To: suse-linux-uk-schools@suse.com Subject: Re: [suse-linux-uk-schools] Hi all
May I ask what kind of work? What I'd really love is for somebody to make it possible to restrict the things that are possible in KDE -- for example so that a school could use it on the desktop without the kids fiddling with all the settings.
I did notice however something that Waldo put on:
http://developer.kde.org/development-versions/kde-3.0-release-plan.html
about preventing users changing the wallpaper, and stuff. [Simon Wood]
Can't this be done by sym-linking the appropriate parts of '.kde' to a non writable master copy. I though I'd limit my users (my wife) in this fashion but see told me not to....
The problem is you can need to think quite hard about exactly what you link. IMHO it's a design defficency quite a bit of software (not just KDE) has, apparently copied from Windows. Which is to make everything only end user configurable. Which is a pain where not only don't you want the end user configuring things they wouldn't have the first clue anyway. (I find web browser settings an especial annoyance.)
You could also limit access to the config application. Ah the power of the UID....
-- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
On Mon, 3 Dec 2001, Mark Evans wrote:
Can't this be done by sym-linking the appropriate parts of '.kde' to a non writable master copy. I though I'd limit my users (my wife) in this fashion but see told me not to.... The problem is you can need to think quite hard about exactly what you link.
And what is supposed to prevent users deleting the symlinks?
IMHO it's a design defficency quite a bit of software (not just KDE) has, apparently copied from Windows. Which is to make everything only end user configurable. Which is a pain where not only don't you want the end user configuring things they wouldn't have the first clue anyway. (I find web browser settings an especial annoyance.)
Personally, I think that the most elegant solution is for applications to merge both central and per-user settings. KDE does this - you can create settings in /usr/share/config/* that will apply to all applications, but can be overridden by end users when necessary. It always irritates me when I have to use a system on which the user interface has been locked down in the interests of 'security'. This is, as far as I can tell, a practice that originates from the days of Windows 95, when you had to lock down the user interface simply because the underlying system didn't provide any security itself. This is not the case with Linux; even if you leave the full user interface exposed there is very little that users can do that will affect anything beyond their own personal settings. We have had no problems with providing "unlocked" user interfaces to both primary- and secondary-age students on both Linux and WinNT platforms. Not a single issue has yet arisen due to students playing around with settings, in over four years. I think the key is to ensure that users don't ever have to wander in to the settings and start fiddling. Make it all "just work" in the first place. It can be done. Users should always be able to sit down and just start using a piece of software, without having to set anything up first. For the record, and because it's mildly relevant to this discussion, we are currently creating a policy-type configuration tool. The idea is that you don't bother to configure any individual computers on the network (even servers); instead you create configuration rules from which every computer can derive their configuration. For example, you create a rule that says "the proxy server is SERVER1". From this, SERVER1 knows that it must install and start up Squid. Simultaneously, all the other computers on the network know that they must set SERVER1 as the proxy server for all installed browsers. Please note *all* computers and *all* browsers: this rule would apply to Konqueror, Netscape, Galeon, Opera, MSIE, lynx, etc. - the same configuration rule applies to multiple different pieces of software across multiple platforms. We are planning a release on SourceForge soon (will be at fenconfig.sourceforge.net, but nothing has yet been uploaded). It will be GPL. [ We have already planned for a category of rules that deal with locking down user interfaces. The category title will be "User Irritants". :-) ] Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 03 December 2001 4:11 pm, Michael Brown wrote:
It always irritates me when I have to use a system on which the user interface has been locked down in the interests of 'security'. This is, as far as I can tell, a practice that originates from the days of Windows 95, when you had to lock down the user interface simply because the underlying system didn't provide any security itself. This is not the case with Linux; even if you leave the full user interface exposed there is very little that users can do that will affect anything beyond their own personal settings.
Absolutely true. But would you really want users changing their personal settings (and possibly making a mess -> wasted time for the administrator) when they could be doing more productive things?
We have had no problems with providing "unlocked" user interfaces to both primary- and secondary-age students on both Linux and WinNT platforms. Not a single issue has yet arisen due to students playing around with settings, in over four years.
I personally find that very interesting -- and I doubt it would be that simple in most places. Certainly from my experience, just leaving it like that would be a recipe for disaster.
For the record, and because it's mildly relevant to this discussion, we are currently creating a policy-type configuration tool. The idea is that you don't bother to configure any individual computers on the network (even servers); instead you create configuration rules from which every computer can derive their configuration. For example, you create a rule that says "the proxy server is SERVER1". From this, SERVER1 knows that it must install and start up Squid. Simultaneously, all the other computers on the network know that they must set SERVER1 as the proxy server for all installed browsers. Please note *all* computers and *all* browsers: this rule would apply to Konqueror, Netscape, Galeon, Opera, MSIE, lynx, etc. - the same configuration rule applies to multiple different pieces of software across multiple platforms.
Sounds like a very interesting project. I look forward to trying it out :) - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8C8YwF8Iu1zN5WiwRAj0CAKCZpdDdir7q2oZT3EYZvX1776jNdQCcDEXV yYsoOCKR8N+MyIcQwJIELuI= =f7d8 -----END PGP SIGNATURE-----
On Monday 03 December 2001 18:36, Chris Howells wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 03 December 2001 4:11 pm, Michael Brown wrote:
It always irritates me when I have to use a system on which the user interface has been locked down in the interests of 'security'. This is, as far as I can tell, a practice that originates from the days of Windows 95, when you had to lock down the user interface simply because the underlying system didn't provide any security itself. This is not the case with Linux; even if you leave the full user interface exposed there is very little that users can do that will affect anything beyond their own personal settings.
Absolutely true. But would you really want users changing their personal settings (and possibly making a mess -> wasted time for the administrator) when they could be doing more productive things?
The teacher has a role here! Kids can destroy all their books but they don't because they have been taught not to. Part of learning is to be responsible and if you foul up your own computer time by being an idiot its a good lesson to learn. On balance I think heavily locked down systems are worse. I am constantly in schools with teachers moaning about an inability to do anything in their own user directory. We wasted an entire training session because the person with the password was off and no-one else could get us in so we could install the relevant software even on a local machine. Regards, -- IanL
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 03 December 2001 9:44 pm, Ian wrote:
don't because they have been taught not to. Part of learning is to be responsible and if you foul up your own computer time by being an idiot its a good lesson to learn. On balance I think heavily locked down systems are worse. I am constantly in schools with teachers moaning about an inability to do anything in their own user directory. We wasted an entire training session because the person with the password was off and no-one else could get us in so we could install the relevant software even on a local machine.
OK, imagine this. Your proxy server provides filtered access to the internet. Because it isn't a transparent proxy, people's browsers must be configured to use the proxy. However, people can easily change the proxy setting via the Settings dialog in Konqueror. This is one thing that my app would hopefully address. - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8DI7rF8Iu1zN5WiwRAnClAJ9YydvRPowIC1DW4JNFiT+Eu1dKXgCePBGZ OQVMRQAnH2/+iZTG98dCRLo= =t4f5 -----END PGP SIGNATURE-----
OK, imagine this. Your proxy server provides filtered access to the internet. Because it isn't a transparent proxy, people's browsers must be configured to use the proxy.
However, people can easily change the proxy setting via the Settings dialog in Konqueror.
On our system we address this by having only one outbound http (8080) hole in our firewall, explicitly linking our proxy with RM's proxy. -- Christopher Dawkins, Felsted School, Dunmow, Essex CM6 3JG 01371-820527 or 07798 636725 cchd@felsted.essex.sch.uk
On Mon, 3 Dec 2001, Chris Howells wrote:
It always irritates me when I have to use a system on which the user interface has been locked down in the interests of 'security'. This is, as far as I can tell, a practice that originates from the days of Windows 95, when you had to lock down the user interface simply because the underlying system didn't provide any security itself. This is not the case with Linux; even if you leave the full user interface exposed there is very little that users can do that will affect anything beyond their own personal settings. Absolutely true. But would you really want users changing their personal settings (and possibly making a mess -> wasted time for the administrator) when they could be doing more productive things?
I have no problem with people customising their desktop. In fact, one of our primary schools uses this as the "introduction to the computer suite" lesson: the students are shown how to log on and how to play around with their wallpaper etc. It's a good way for them to get familiar with the interface without being distracted by anything extraneous (typing exercises, etc.). Out of well over 1000 users of systems that I have configured, used by ages 5 to 60, I have yet to have any of my time wasted by users making a mess by changing their personal settings.
We have had no problems with providing "unlocked" user interfaces to both primary- and secondary-age students on both Linux and WinNT platforms. Not a single issue has yet arisen due to students playing around with settings, in over four years. I personally find that very interesting -- and I doubt it would be that simple in most places. Certainly from my experience, just leaving it like that would be a recipe for disaster.
My experience has taught me otherwise. In addition, I have heard many more tales of problems caused by locked-down systems than I have heard tales of problems caused by systems left 'open'. (Obviously I'm talking about just the user interface here, not the underlying system security). It's probably worth noting that I try very, very hard to ensure that users are never forced to deal with any setup or configuration issues themselves. For example, at one large WinNT/2000 site we have made it possible for users to transparently move between Netscape 4 and Netscape 6. This is something that the Mozilla authors don't seem to have envisioned - NS6 provides only a one-way migration path from NS4 - but it's necessary for this site because there are several hundred roaming users and we don't want to upgrade all 200 workstations simultaneously (even using Ghost). It took about a day to hack round the various incompatibilities, but now users can simply start Netscape and have all their mail folders, bookmarks, settings etc. available without worrying about which version it is. My view is that if users have to do anything other than (double-)click to start up an application, then this should be viewed as a bug. This is one of the major gripes I have with programs such as KDevelop that go through an extensive setup routine the first time the user runs the program. A user interface that requires you to just repeatedly click on "Next" shouldn't be there!
For the record, and because it's mildly relevant to this discussion, we are currently creating a policy-type configuration tool. The idea is that you don't bother to configure any individual computers on the network (even servers); instead you create configuration rules from which every computer can derive their configuration. For example, you create a rule that says "the proxy server is SERVER1". From this, SERVER1 knows that it must install and start up Squid. Simultaneously, all the other computers on the network know that they must set SERVER1 as the proxy server for all installed browsers. Please note *all* computers and *all* browsers: this rule would apply to Konqueror, Netscape, Galeon, Opera, MSIE, lynx, etc. - the same configuration rule applies to multiple different pieces of software across multiple platforms. Sounds like a very interesting project. I look forward to trying it out :)
I'll send a single mail to the list when something is uploaded. The base functionality is already there, including a very neat trick that correctly resolves circular references between configuration rules[1]. I'm now thinking about the problem of how machines (in particular newly-installed machines) could identify themselves in order to work out which parts of the rule sets should apply to them. Harder than it sounds... [1] Note: "resolves", not "detects". It's easy to detect a circular reference and just abort: the trick is in working out how to abort only when the circular reference doesn't have a valid, stable solution. (i.e. "x=x" can have a solution whereas "x=!x" cannot). Michael
On Mon, 3 Dec 2001, Chris Howells wrote:
It always irritates me when I have to use a system on which the user interface has been locked down in the interests of 'security'. This is, as far as I can tell, a practice that originates from the days of Windows 95, when you had to lock down the user interface simply because the underlying system didn't provide any security itself. This is not the case with Linux; even if you leave the full user interface exposed there is very little that users can do that will affect anything beyond their own personal settings. Absolutely true. But would you really want users changing their personal settings (and possibly making a mess -> wasted time for the administrator) when they could be doing more productive things?
I have no problem with people customising their desktop. In fact, one of
Part of the issue is what consitutes "customising their desktop".
our primary schools uses this as the "introduction to the computer suite" lesson: the students are shown how to log on and how to play around with their wallpaper etc. It's a good way for them to get familiar with the
Current Linux desktops also changing source email addresses just as easy as changing wallpaper and colour schemes. This is the sort of thing I mean by a need to restrict what a user can do. IMHO there should be some things a user can change easily, there should be some things they can change with difficulty and some things a user cannot change at all. The latter is things which if altered will result in things just failing to work. But exactly which things these are may depend on both site policies and even per user. (e.g. someone who given half a chance will fiddle to the exculsion of doing any work might be best off with something they can't alter at all.) With some things there may be no "right" answer of if something is a "user" or a "system" configuration.
My view is that if users have to do anything other than (double-)click to start up an application, then this should be viewed as a bug. This is one of the major gripes I have with programs such as KDevelop that go through an extensive setup routine the first time the user runs the program. A user interface that requires you to just repeatedly click on "Next" shouldn't be there!
I agree 100% here. I'd also include things such as Star Office, Netscape, etc. Which in their default configuration attempt to generate a profile from user input where not only does the computer usually have all the information if the user makes a mistake they are going to be utterly lost. However the people who write these programs rarely appear to consider usage on a multi-user system or LAN. Thus you can end up spending quite a lot of time writing wrapper scripts so the program will "just work" when run by a user. -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
On Mon, Dec 03, 2001 at 10:36:01PM +0000, Michael Brown wrote:
On Mon, 3 Dec 2001, Chris Howells wrote:
It always irritates me when I have to use a system on which the user interface has been locked down in the interests of 'security'. This is, as far as I can tell, a practice that originates from the days of Windows 95, when you had to lock down the user interface simply because the underlying system didn't provide any security itself. This is not the case with Linux; even if you leave the full user interface exposed there is very little that users can do that will affect anything beyond their own personal settings. Absolutely true. But would you really want users changing their personal settings (and possibly making a mess -> wasted time for the administrator) when they could be doing more productive things?
I have no problem with people customising their desktop. In fact, one of our primary schools uses this as the "introduction to the computer suite" lesson: the students are shown how to log on and how to play around with their wallpaper etc. It's a good way for them to get familiar with the interface without being distracted by anything extraneous (typing exercises, etc.).
I do have a problem with people customising their desktops - it's an inordinate waste of time. OK it might be a good way for them to familiarise themselves with the interface but in the long run it means that they'll end up wasting huge amounts of time prettifying and re-prettifying their desktops - I know since I'm guilty of it too. Time and motion studies of people at work at their PCs show that they spend >25% of their time doing just that.
Out of well over 1000 users of systems that I have configured, used by ages 5 to 60, I have yet to have any of my time wasted by users making a mess by changing their personal settings.
You obviously lock down the important stuff so your time isn't wasted but that doesn't obviate the fact that their time is.
We have had no problems with providing "unlocked" user interfaces to both primary- and secondary-age students on both Linux and WinNT platforms. Not a single issue has yet arisen due to students playing around with settings, in over four years. I personally find that very interesting -- and I doubt it would be that simple in most places. Certainly from my experience, just leaving it like that would be a recipe for disaster.
My experience has taught me otherwise. In addition, I have heard many more tales of problems caused by locked-down systems than I have heard tales of problems caused by systems left 'open'. (Obviously I'm talking about just the user interface here, not the underlying system security).
What sort of problems? <snip>
My view is that if users have to do anything other than (double-)click to start up an application, then this should be viewed as a bug. This is one of the major gripes I have with programs such as KDevelop that go through an extensive setup routine the first time the user runs the program. A user interface that requires you to just repeatedly click on "Next" shouldn't be there!
Agreed. When you're installing the program on a number of machines you should be just able to copy an rc file to all the users home dirs, which in a way comes back to my pro-`locked down' argument. The policy editor which others on this list are discussing seems like a cool idea - it sounds like it would suit both liberal admins like you and BOFHs like me ;-) <snip> -- Frank *-*-*-*-*-*-*-*-*-*-* Boroughbridge. Tel: 01423 323019 --------- PGP keyID: 0xC0B341A3 *-*-*-*-*-*-*-*-*-*-* http://www.esperance-linux.co.uk/ Plumbing is one of the easier of do-it-yourself activities, requiring only a few simple tools and a willingness to stick your arm into a clogged toilet. -- Dave Barry, "The Taming of the Screw"
On Wed, 5 Dec 2001, Frank Shute wrote:
I have no problem with people customising their desktop. In fact, one of our primary schools uses this as the "introduction to the computer suite" lesson: the students are shown how to log on and how to play around with their wallpaper etc. It's a good way for them to get familiar with the interface without being distracted by anything extraneous (typing exercises, etc.). I do have a problem with people customising their desktops - it's an inordinate waste of time. OK it might be a good way for them to familiarise themselves with the interface but in the long run it means that they'll end up wasting huge amounts of time prettifying and re-prettifying their desktops - I know since I'm guilty of it too. Time and motion studies of people at work at their PCs show that they spend >25% of their time doing just that.
That's interesting. On the other hand, maybe it's symptomatic of a deeper problem: the lack of really *interesting* thinks to do on a computer? I certainly remember that back when my old school changed BBCs for PCs people stopped writing programs in BBC BASIC and started fiddling with GUI settings instead. For anyone who hasn't yet come across it, I would seriously recommend taking a look at Squeak (www.squeakland.org) as an "interesting things to do with computers for just about anyone of any age" program. Squeak is currently my number two favourite application of all time. No description could really do it justice - you have to try it out.
My experience has taught me otherwise. In addition, I have heard many more tales of problems caused by locked-down systems than I have heard tales of problems caused by systems left 'open'. (Obviously I'm talking about just the user interface here, not the underlying system security). What sort of problems?
Not being able to install software (business environment), not being able to save work because the floppy has run out of space and there is no access to the hard disk, not being able to diagnose faults because Start-Run was disabled, not being able to configure networking even with the administrator password (RM WindowBox), not being able to put in the *correct* proxy settings when the proxy server changed, not being able to shut the machine down cleanly because only administrators can shut down the machine, not being able to do *anything* because Win2K decided that the local administrator did not have administrative privileges (and simultaneously refused to allow domain logons)... It's been possible to work around almost all of these. For example, you can use NT's AT command to start up cmd.exe running as LocalSystem, which enables you to bypass all local machine access restrictions. They simply cause an irritating delay. More worryingly is that many people will assume that locking down the user interface actually makes the system secure... Michael
Michael Brown wrote:
Not being able to install software (business environment), not being able to save work because the floppy has run out of space and there is no access to the hard disk, not being able to diagnose faults because Start-Run was disabled, not being able to configure networking even with the administrator password (RM WindowBox), not being able to put in the *correct* proxy settings when the proxy server changed, not being able to shut the machine down cleanly because only administrators can shut down the machine, not being able to do *anything* because Win2K decided that the local administrator did not have administrative privileges (and simultaneously refused to allow domain logons)...
This is good stuff. Of course I lock down the desktop! Everyone does - right? Well, it seems not... I'd never put any hard thought into _whether_ I needed to lock down the User Interface, just exhaustively thought about _how_. I will of course tread carefully, but may think about releasing some of the tight controls that cause users annoyance. I've always imagined (and I have no evidence of this) that, for example, icons will get swept into the recycle bin with some inaccurate clicking, and then I will be called upon to fix that child's (read adults's) desktop because 'Acrobat Reader has been completely wiped off my machine'. Of course, this sort of thing could happen, but could it be perhaps, that it causes less hassle than the lock down. Perhaps I might have a test by releasing the interface for one year group, and seeing what happens. It would be very easy to put back by enforcing the mandatory policy again (yes, it's Windows (I typed that word very quickly indeed - no one saw, right?)). It's certainly food for thought. Incidently, I get a lot of help and information from this list. I, for one, feel that the technical and political discussions are relevant to me (and I'm a Primary school ICT coordinator). I do feel that some of us should take a deep breath before replying. The tone can be too personal at times. I don't think there's room for insults in the community. And certainly no room for "but he started it". One of the huge thing that attracts me to a list like this, and to software like Linux, is the community. Most important of all: I have received a _lot_ of help from folks here, and our school has cost-effective, professional network services because of it. There's no way I would have got this far without the "which network card driver do I use" style questions I've posted (and I'm fairly sure no one could accuse those sort of questions, by a newbie ICT coordinator, off topic). -- Matt __________________________________________________ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com
On Wed, Dec 05, 2001 at 01:37:56PM +0000, Michael Brown wrote:
I do have a problem with people customising their desktops - it's an inordinate waste of time. OK it might be a good way for them to familiarise themselves with the interface but in the long run it means that they'll end up wasting huge amounts of time prettifying and re-prettifying their desktops - I know since I'm guilty of it too. Time and motion studies of people at work at their PCs show that they spend >25% of their time doing just that.
That's interesting. On the other hand, maybe it's symptomatic of a deeper problem: the lack of really *interesting* thinks to do on a computer? I certainly remember that back when my old school changed BBCs for PCs people stopped writing programs in BBC BASIC and started fiddling with GUI settings instead.
I think you're right, it is symptomatic of a deeper problem. People are using computers for the wrong things and I think the GUI is the guilty party. I think that programming is the *really* interesting thing to do on a computer. People have forgotten that the primary purpose of computers is to do repetitive tasks - something a GUI very much gets in the way of. I kicked off on a computer writing DOS batch files because it allowed me to automate various tedious administrative tasks. Now I spend a lot of time writing shell and perl scripts for the very same reasons but I've now got the ability to write what could be termed fairly sophisticated programs. But what happens if your introduction to computing is fiddling with your GUI? Where are you going to go from there? In computing terms, nowhere. Which is why IMO kids at school shouldn't be learning to muck around with GUIs or use large monolithic apps such as word-processors because in computing terms these take you nowhere and should be learnt at home if they feel that they need to learn them - they've got nothing to do with IT really and shouldn't be taught in an IT class. It's been commented on here before that there is a dearth of people who actually know how to use a computer in any meaningful way and hence the pool of `computing professionals' is filled with people who don't actually know anything about computing yet waive their MSCEs around with the assumption that it gives them legitimacy - it doesn't. They're graduates with Hons from the GUI School of Fiddlers.
For anyone who hasn't yet come across it, I would seriously recommend taking a look at Squeak (www.squeakland.org) as an "interesting things to do with computers for just about anyone of any age" program. Squeak is currently my number two favourite application of all time. No description could really do it justice - you have to try it out.
Sounds intriguing - I'll look into it.
My experience has taught me otherwise. In addition, I have heard many more tales of problems caused by locked-down systems than I have heard tales of problems caused by systems left 'open'. (Obviously I'm talking about just the user interface here, not the underlying system security). What sort of problems?
Not being able to install software (business environment), not being able to save work because the floppy has run out of space and there is no access to the hard disk, not being able to diagnose faults because Start-Run was disabled, not being able to configure networking even with the administrator password (RM WindowBox), not being able to put in the *correct* proxy settings when the proxy server changed, not being able to shut the machine down cleanly because only administrators can shut down the machine, not being able to do *anything* because Win2K decided that the local administrator did not have administrative privileges (and simultaneously refused to allow domain logons)...
OK point taken. I now remember why I always log into NT as admin and use FSTAB rather than NTFS :)
It's been possible to work around almost all of these. For example, you can use NT's AT command to start up cmd.exe running as LocalSystem, which enables you to bypass all local machine access restrictions. They simply cause an irritating delay.
More worryingly is that many people will assume that locking down the user interface actually makes the system secure...
There's a problem with multi-user Windows systems because of their single-user legacy which is why unix/linux wins in these situations in administrative terms. I bet you don't have nearly as many problems with your unix boxes in multi-user environments. -- Frank *-*-*-*-*-*-*-*-*-*-* Boroughbridge. Tel: 01423 323019 --------- PGP keyID: 0xC0B341A3 *-*-*-*-*-*-*-*-*-*-* http://www.esperance-linux.co.uk/ You need more time; and you probably always will.
On Thu, 6 Dec 2001, Frank Shute wrote:
I do have a problem with people customising their desktops - it's an inordinate waste of time. OK it might be a good way for them to familiarise themselves with the interface but in the long run it means that they'll end up wasting huge amounts of time prettifying and re-prettifying their desktops - I know since I'm guilty of it too. Time and motion studies of people at work at their PCs show that they spend >25% of their time doing just that.
Just to throw a bit more fuel on: I asked the IT co-ordinator at the (primary) school I was visiting today what her opinion was on the issue of locking down the desktops. She was quite adamant that she preferred the students to be able to personalise their desktops because: 1. It got them familiar with using the interface: clicking, dragging, context-sensitive menus, dialogs, tabs, OK/Apply/Cancel etc. 2. It meant they could have personal environments - the students feel that it's more 'their' computer if they can customise it. [ Of course, this would be a very *bad* thing if the students were able to make changes that affected other users, but this is not the case ] I asked about the issue of time-wasting and she said it didn't really happen. Students would change the background every so often when they logged on and decided they were "bored with that colour", but this generally happened during computer club time rather than lesson time. Incidentally, I noticed that KDE's Hue Shift Blending is very popular, possibly because it means everyone can come up with a unique desktop with very little effort. Food for thought... Michael
On Wednesday 05 December 2001 1:37 pm, Michael Brown wrote: [bigsnip]
It's been possible to work around almost all of these. For example, you can use NT's AT command to start up cmd.exe running as LocalSystem, which enables you to bypass all local machine access restrictions. They simply cause an irritating delay.
Is this as seriously un-secure as it sounds? It is this simple to bypass all security features on NT? (This is a serious question - I've got no NT experience but may be having it forced on me soon)
More worryingly is that many people will assume that locking down the user interface actually makes the system secure...
Michael
-- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000
On Thu, 6 Dec 2001, Gary Stainburn wrote:
It's been possible to work around almost all of these. For example, you can use NT's AT command to start up cmd.exe running as LocalSystem, which enables you to bypass all local machine access restrictions. They simply cause an irritating delay. Is this as seriously un-secure as it sounds? It is this simple to bypass all security features on NT? (This is a serious question - I've got no NT experience but may be having it forced on me soon)
You do need privileges to run the AT command in the first place, and you also need the Schedule service to be running (or have privileges to start the Schedule service). It's a way of elevating your privileges - if you end up trapped with a cut-down administrator-like account then you can quickly and easily grant yourself unrestricted access to the whole local machine. I have used this trick several times, particularly when Win2000 was playing up and refusing to believe that the local Administrator actually had full administrative rights. One neat side-effect is that this method allows you to directly edit the SAM database. NT usually prevents even administrators from directly reading and writing the SAM database with tools such as Registry Editor, but if you grant yourself LocalSystem privileges then you can just fire up regedt32 and browse into the 'forbidden' HKLM\SECURITY tree. In summary: it doesn't allow ordinary users to gain admin privileges but it does allow some restricted admin users to bypass their restrictions. Michael
On Mon, 3 Dec 2001, Mark Evans wrote:
Can't this be done by sym-linking the appropriate parts of '.kde' to a non writable master copy. I though I'd limit my users (my wife) in this fashion but see told me not to.... The problem is you can need to think quite hard about exactly what you link.
And what is supposed to prevent users deleting the symlinks?
IMHO it's a design defficency quite a bit of software (not just KDE) has, apparently copied from Windows. Which is to make everything only end user configurable. Which is a pain where not only don't you want the end user configuring things they wouldn't have the first clue anyway. (I find web browser settings an especial annoyance.)
Personally, I think that the most elegant solution is for applications to merge both central and per-user settings. KDE does this - you can create settings in /usr/share/config/* that will apply to all applications, but can be overridden by end users when necessary.
Somtimes you want to be able to disable certain per user settings. Either because they will result in things not working e.g. web browser proxy settings. Or because the risk of causing problems for other people is high e.g. the From: field in emails. (In schools either users shouldn't be able to change this or a Sender: header must be generated.) The latter is something the older text based software handles far far better then any GUI software, IMHO.
For the record, and because it's mildly relevant to this discussion, we are currently creating a policy-type configuration tool. The idea is that you don't bother to configure any individual computers on the network (even servers); instead you create configuration rules from which every computer can derive their configuration. For example, you create a rule that says "the proxy server is SERVER1". From this, SERVER1 knows that it must install and start up Squid. Simultaneously, all the other computers on the network know that they must set SERVER1 as the proxy server for all installed browsers. Please note *all* computers and *all* browsers: this rule would apply to Konqueror, Netscape, Galeon, Opera, MSIE, lynx, etc. - the same configuration rule applies to multiple different pieces of software across multiple platforms.
Lynx already handles proxy settings very effectivly through environment variables. The others not so well... -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763
What I'd really love is for somebody to make it possible to restrict the things that are possible in KDE -- for example so that a school could use it on the desktop without the kids fiddling with all the settings.
It seems to me that this is (a) extremely easy & (b) rather difficult It is easy because it is all controlled by text files in areas (on our system) such as /usr/share/applnk and /usr/share/config and ~/.kde/share. These text files are easily edited by hand or by scripts, which might be run by cron, and easily protected against user modification if the users don't have root access. It is difficult because you need to know the structure of the applnk and config and rc files and the interactions between them, and you then need to know how to write the appropriate scripts. -- Christopher Dawkins, Felsted School, Dunmow, Essex CM6 3JG 01371-820527 or 07798 636725 cchd@felsted.essex.sch.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 03 December 2001 10:17 pm, Christopher Dawkins wrote:
It is easy because it is all controlled by text files in areas (on our system) such as /usr/share/applnk and /usr/share/config and ~/.kde/share. These text files are easily edited by hand or by scripts, which might be run by cron, and easily protected against user modification if the users don't have root access.
It is difficult because you need to know the structure of the applnk and config and rc files and the interactions between them, and you then need to know how to write the appropriate scripts.
I agree. ;) That's what my app would hopefully address. It turns out that another KDE developer has done quite a lot of work on looking at this. You can find his ideas at http://webcvs.kde.org/kdelibs/kdecore in the file README.kiosk. Hopefully I will be able to share some ideas with him. - -- Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://edu.kde.org, http://usability.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8DI5PF8Iu1zN5WiwRAtM8AJwNWQuBH2cQhkDnsj7bH4kAnb8nwQCdE/QU IyOw9OFDJTeGnz4Dg1kvC8s= =FBRs -----END PGP SIGNATURE-----
On Mon, Dec 03, 2001 at 10:17:08PM +0000, Christopher Dawkins wrote:
What I'd really love is for somebody to make it possible to restrict the things that are possible in KDE -- for example so that a school could use it on the desktop without the kids fiddling with all the settings.
It seems to me that this is (a) extremely easy & (b) rather difficult
It is easy because it is all controlled by text files in areas (on our system) such as /usr/share/applnk and /usr/share/config and ~/.kde/share. These text files are easily edited by hand or by scripts, which might be run by cron, and easily protected against user modification if the users don't have root access.
It is difficult because you need to know the structure of the applnk and config and rc files and the interactions between them, and you then need to know how to write the appropriate scripts.
I would have thought some sort of XML based tool would make sense since there are already plenty of tools to deal with XML (ie. editors), it would be easy to hack a parser together and it's just plain text. Mozilla makes use of an XML for configuration purposes: http://www.mozilla.org/unix/customizing.html -- Frank *-*-*-*-*-*-*-*-*-*-* Boroughbridge. Tel: 01423 323019 --------- PGP keyID: 0xC0B341A3 *-*-*-*-*-*-*-*-*-*-* http://www.esperance-linux.co.uk/ The problems of business administration in general, and database management in particular are much too difficult for people that think in IBMese, compounded with sloppy english. -- Edsger Dijkstra
participants (9)
-
Chris Howells -
Christopher Dawkins -
Frank Shute -
Gary Stainburn -
Ian -
Mark Evans -
Matt Johnson -
Michael Brown -
Simon Wood