| Date: | September 21, 2006 / year-entry #322 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060921-02/?p=29643 |
| Comments: | 34 |
| Summary: | Occasionally, a customer will ask for a way they can restrict what the administrator can do. The short answer to this is, "Um, no, that's why they're called 'Administrator'." You can try to set up roadblocks, say, ACL files to revoke access to a file you don't want the administrator to read, but the Administrator... |
Occasionally, a customer will ask for a way they can restrict what the administrator can do. The short answer to this is, "Um, no, that's why they're called 'Administrator'." You can try to set up roadblocks, say, ACL files to revoke access to a file you don't want the administrator to read, but the Administrator can always take ownership of the file and read the contents that way. At the end of the day, the Administrator owns the local machine. Often, people ask this question because they want to grant certain employees selected subsets of the full set of capabilities available to the Administrator. The way to do this is not to make the user an administrator and then try to rope off the parts you don't want them to use. Rather, you take the things that you do want them to be able to do and delegate that permission and only that permission to them (discretionary access control). For more information, check out this column on trustworthy administrators (based, I am told, on a TechEd presentation) by Steve Riley (and his uncredited co-presenter Jesper Johansson). |
Comments (34)
Comments are closed. |
I am always surprised at the high number of people who completely fail to understand basic security principles such as this. Already I have a client asking me for a way to limit a user while maintaining that user’s sovereignty over the machine (i.e. admin rights). And that makes about the 9th time this year I have been given such a request.
James
Ok then, how do you make a user capable of installing software, while not being able to read other users’ files?
You can’t. Almost all installers won’t work unless you are a member of the Administrators group.
Stu: Try sudo, and configure /etc/sudoers to allow trusted users to run (with either no password or their password) whatever install command is required, but not allow them to run anything else.
Oh, wait… ;-)
(Actually, I wonder if anyone has ported sudo to Windows, or written something that works just like it but that runs on Windows. Hmm.)
BryanK,
There’s "Run as" which you get by right-clicking on an executable.
sudo has existed for windows for a long time. you can log in as… (user) for any app desire. That’s what the secondary login service is for
"Run as" isn’t nearly the same as sudo, because you need a second account’s full credentials to "run as" something. Once you give a user that password, they have full access to the machine anyway, because they can just log in as that user, or run anything they want with "run as". And if you don’t give them that password, then you haven’t actually given the user access to anything, have you?
sudo, on the other hand, doesn’t need another account’s password. Instead, you get to define a list of commands that users can run with administrative rights, under their own credentials. This means access can be given, changed, and revoked without having to change anyone’s password, and without having to maintain more than a 1:1 ratio of accounts:users.
Run As fails for at least some ‘complex’ installations (installer calls installer) anyway.
Or perhaps this is a kind of security.
The weakness of sudo is the "approved" programs must also be security concious and robust.
How many idiots assume that if you can look at the Security event log, you must be an Administrator?
That assumption is wrong if log viewing was done with sudo.
How many non-suid programs have exploitable bugs that are harmless if run by root – because you ARE root – but could be exploited by a regular using using sudo, thereby gaining root privs?
I like sudo. I just don’t trust software.
The problem with sudo is that it requires specific commands. How do I know in advance what command is going to be used to install the software that somebody’s going to need? And what’s to say that they don’t have the "evil" version of that command that installs spyware instead of what they’re supposed to have?
The only way to keep admins from accessing data they’re not allowed to see is to encrypt it.
I read somewhere (might have been Jesper’s blog, might have been here, I can’t recall) the slogan "Power Users are just users that have not made themselves Administrators yet." Or in other words, don’t try to make untrusted users Power Users to let them do certain tasks, instead do what Raymond said above.
If they can access the machines’ network port, the even apt-get can be subverted.
Asking for restrictions on admin power isn’t new – that’s the whole point of DRM, intellectual property protection, anti-cheat, and so on.
There are plenty of examples, Microsoft and everywhere alkie, that implement "how do I prevent the owner of a computer from using a debugger" or whatever.
apt-get accepts "-c" which tells it which config file to use. The config file can specify the HTTP proxy. Point the proxy at localhost, run server to serve up a package that overwrites arbitary files on the system.
Toast. And you didn’t even need to cut the Ethernet.
sudo keeps honest people honest and prevents stupid mistakes. sudoers are just power users who haven’t made themselves root yet. :=)
PS Raymond, I routinely try to install software as a limited user. The software – er, spyware – will work for me but if perms are correct and there aren’t any cracks in Windows, then the spyware will only be able to read MY files. Not anyone elses on the computer.
Most software houses just don’t understand the per-user concept.
Exactly as Neal C just said — sudo doesn’t have to ask you for the administrator’s password (but runas does). Sudo can be configured to either ask you for your own password, or no password at all. Or different settings depending on what command you’re running.
(And "sudo setup best practices" obviously include only setting this up for a small number of specific commands, excluding anything that will give the user a (root) shell.)
However, reading Raymond’s response to Stu, I’d have to agree. If you’re allowed to install anything, you can (very likely) install a kernel-mode driver, such as a screen-scraper or a keylogger. It may be possible to make changes that would limit this capability (and maybe not), but AFAIK nothing exists today in Windows to do that. So Raymond’s right: even a sudo equivalent wouldn’t help with that.
(In fact, even on a system that has sudo, it *may* be possible to install a spyware-type program. Using Debian as an example (just because I know it fairly well), say you allow "sudo apt-get install", and only that, for a certain user. If that user can find a package in one of the package repositories that are listed in apt-get’s sources.list file, they would be able to install that package. Of course hopefully Debian wouldn’t include a spyware package in their official package repos, but I wouldn’t want to bet on that being the *only* line of defense, either.)
> The problem with sudo is that it requires specific commands.
Actually, it doesn’t. You can allow a user access to anything if you want, but then you’ve basically given them root. (That’s why the "best practices" are to limit by command. But it’s not a requirement of using the program.)
Even so, see below.
> How do I know in advance what command is going to be used to install the software that somebody’s going to need?
It’ll be "apt-get install <some-package-name>" on Debian, preferably with no other arguments. (Or possibly "dpkg -i <blah>.deb", but that bypasses the sources.list check, and — IMO anyway — should require root, not just sudo privileges. Same with "make install". For that matter, same with anything else that bypasses the dpkg database. Actually, there’s not that much that *isn’t* available in one official Debian repository or another, so this shouldn’t come up all that often either.)
Sudo can filter on more than just which program they’re running; it can filter on all the arguments they give to it.
> And what’s to say that they don’t have the "evil" version of that command that installs spyware instead of what they’re supposed to have?
They don’t have write permission to /bin or /usr/bin, so they can’t have replaced the apt-get executable. (Or whichever executable your distro uses to install packages.) Now, they might be able to install a different apt package that overwrites the binary, then use that to install something else. Hmm. But again, this would require that either someone put the evil package’s repository into sources.list, or the evil package got into Debian’s official sources.list.
Still probably unlikely, but it’s still a single line of defense. Sudo’s not a panacea, I guess I’m saying, but it is helpful.
Err, what happens if you don’t trust your Administration? For instance, shouldn’t an OS come with checks and balances, so that there are two kinds of Administrators, one (called the Executive) who can do all the usual Admin things, EXCEPT for administering auditing. The other administrator can audit what the Executive has done. That way, if the Executive stores 14 illegal files in his Gitmo folder, the auditor is able to catch him out.
Raymond> You just need access to the network cable anywhere between the target machine and the Debian server
How does Windows Update get around this problem?
[You’re asking for a contradiction. If I can install software, then I can install spyware, and therefore I can read other users’ files. -Raymond]
I’d be surprised. If a user can install software, he can install spyware that reads his files. Not other users’ files, or the administrators files.
If you can bypass Read ACLs in spyware, you can almost certainly also bypass Write ACLs, overwrite Notepad.exe with a Trojan and gain admin rights that way. Write permissions are not magically stronger than read permissions. ACLs either work or they don’t. They’re not advisory like the read-only attribute.
The problem indicated is real. Too many installers require admin access.
"For comparison, untrusted government agents can break into your house at any time, so it’s useless to lock your house, yet you often lock your house anyway."
I guess the government is a sort of administrator of the country, i.e. it must be considered to be trusted. E.g. there are lots of things that you might thing the government should be prevented from doing, since if extremists took over the government they may abuse those powers. The problem is that if extremists take over the government they could change the laws to allow whatever they wanted.
So sometimes you’re better off allowing a government, particularly one you trust, to do things that seem illiberal but help to minimise the chances that extremists can take over.
Certainly, if you look at the UK in WWII, the coalition government did highly illiberal things like suspending elections, detaining pro German politicians for the duration of the war to being replaced by an overtly totalitarian Nazi puppet regime. Once the war was over, the coalition split and the Prime Minister’s party lost the election. In many ways, it was a dictatorship in the Roman sense.
Of course, you have to be careful of the situatuon where extremists win an election and use this argument to set up one kind of totalitarian regime whilst claiming to be defending the status quo against another. On the other hand the US constitution should theoretically protect against this sort of possibility.
> apt-get accepts "-c"
But sudoers doesn’t have to allow "apt-get -c anything" to execute. Again, it can check *more* than just the command that’s being run; when using sudo, you give sudo the entire command you want it to run, and it will check all arguments.
As for apt’s repository: The packages are all hashed (with either MD5 or SHA-1, can’t remember which). Then the list of hashes is signed by the official GnuPG-key-of-the-year. So assuming your gpg binary is OK, and assuming you’ve installed the key-of-the-year (this is a problem, as Stu points out; IMO it should be more automatic than it is, but others may not agree), you can verify that the packages have not been tampered with between the server and you.
I believe that current Debian installs will add the current year’s signing key automatically (or at least, the box we have here did that), but that’s still only good until the end of the current year.
(Of course, if someone *wants* to install spyware, then they could just hit "Y" to the "this package is failing verification" message, too. If that’s still an option, anyway.)
Thinking about this some more, encryption isn’t the answer to preventing administrators from seeing your files’ contents either. At least not NTFS encryption (aka EFS), and not CryptProtectData() either.
EFS and CryptProtectData() are based on your user password (basically; I’m omitting a bunch of details here). If you’re logged on as you, you get access to your EFS files, and you can CryptUnprotectData() anything that you’ve CryptProtectData()ed in the past.
However, your admin can do all kinds of things to figure out your password — my favorite is installing a password-change hook DLL on the local DC that writes the new password out somewhere. (We actually do that here, both because people keep forgetting their passwords, and because we sometimes need to log on as them — or unlock their screen without forcibly terminating all their programs — when they’re not here. The target directory has *very* restrictive ACLs on it, of course, and of course it’s a local directory, so the information isn’t floating out over the network.) And if your admin has your password, they can log on as you and see your encrypted files (or CryptUnprotectData() your data).
The only way to stop this is to use an encryption program (or function) that isn’t based on your user credentials, because the admin has those. Also, you’ll have to make it require you to type in some passphrase value before it’ll decrypt anything. Then don’t use a passphrase that’s the same as your password, and don’t write it down anywhere.
Certainly possible, but not as simple as some are claiming either.
(And herein, I am assuming that "administrator" means "domain admin, with admin access to the DC". This is valid for any machine on a domain. It’s not valid for any machine in a home environment, but in a non-domain setup, the administrator can just install their password-change filter DLL on the local machine instead of the DC. The only setup that EFS *might* help with is against a local admin who is *not* a domain admin. Maybe.)
yikes, did someone just use a blog entry about computer security management to make a political statement? I think I’ll go take a shower.
Many windows program require the user to be "administrator". How do I solve this without allowing them to do harmful things?
dilemma — You can’t.
You can try complaining to the author of the software, but that rarely does any good.
Good design!
Well done!
Nice site!
So why does Vista have UAC then?