Windows

Secure, Open, Convenient - Pick Two, and Forget the Other


I have been using Windows Vista for about a week now. One thing that consistently hits me is the UAC system. Even though I am running as an admin, I keep getting asked to verify operations, often by multiple security systems for the same operation. Last night I posted a tip on how to get into the CLI with escalated permissions. A lot of bytes have been used comparing this to sudo (or saying they are not the same). All I know is that Windows is suddenly much less convenient to use.

 

We get three things to consider (in addition to others, like functionality, feature set, etc.)  when we are writing software: secure, open, and convenient. Oddly enough, it seems safe to say that as one or two of these are increased or decreased, the remaining one must go in the opposite direction. It is like an odd variation on Boyle’s Law. In other words, a secure and open system cannot be convenient. A convenient, secure system will not be open. An open, convenient system will not be secure. And so on.

 

For the sake of this post, “open

About

Justin James is the Lead Architect for Conigent.

16 comments
Mike Page
Mike Page

I'm obviously one of those bad programmers. I used to write data to INI files. But, Win 95 came out and the Windows API help said that INI files shouldn't be used, and that I should write to the registry. So, I did just that. But, I wanted the information to be shared by all users that logged onto the machine, so I wrote data to the HKEY_LOCAL_MACHINE branch of the registry. Typically, everyone logs into their own PC as an administrator, because they want to actually be able to use this computer (install software, adjust control panel, etc). One day a user logged onto a machine as a regular user and it broke my app, since they don't have access to that branch of the registry (news to me). So, tried going back to .INI file, but the OS wouldn't create them, since they exist by default in the Windows directory. After many hours of experimentation I found that everyone has access to an application data directory in the user profiles section of the hard drive. I write code everyday. I read tech articles everyday. I know the Windows SDK help very well. But, this is the first posting that I've ever seen that talks about what my apps can and can't do. Where do I find a list of rules that my application must live with?

Jaqui
Jaqui

if you use a true unix or unix like operating system. it's only if you are using something from microsoft that you are right.

Tony Hopkinson
Tony Hopkinson

with the new hardened windows, particularly the installer. We have some of those 'nasty' apps referred to by George Ou. They were originally ported from dos, and have a surfeit of quick fixes in them. In fact they are problematic on occasion in less hardened OS's. Just as one for instance the base class some one wrote for the registry is hard coded to request read/write access and of course it uses Local Machine. Fun times approach. As for your argument, total agreement, you cannot have all three.

Mark Miller
Mark Miller

Don Box said something similar in a talk on .Net several years ago. He said that the more secure a system is the more difficult it is to use. He joked that DCOM was one of the most secure systems in the world, because it was almost impossible to set up and use. I've heard developers sarcastically say about software development, speaking to their hypothetical boss: "You can either have it on time, or it can work. Choose." While I try to avoid these situations, I've run into plenty that are like this. Not telling off my boss, just running into the situation of either I get the deadline extended so I have time to make it work, or wishing I had more time so I didn't have to come in on weekends/stay late to get it working. I'm a bit confused when you say that users cannot make files whenever they want. Could you go in more detail? I've seen this with the default configuration of limited accounts on XP. I would get file access to a couple of places, like My Documents, but nowhere else really, unless I explicitly changed permissions on a folder as Admin. Unix user accounts have been like this for a long time. Your account directory in Unix is like the My Documents folder on Windows. I've had some experience with being limited in what I can and cannot do as a programmer, just on XP and Windows Server 2003. I've run into it as an ASP.Net developer, and as a C++/MFC developer. I wanted to find a way to log what was going on with a web service. So I tried accessing the system event log. I found out I couldn't do that without jumping through a lot of hoops. I tried writing log messages out to a file, and realized I couldn't do that either, because the web service was not given permission to create files. I ended up putting the log messages into the one place the web service did have access, into the database, which wasn't bad, actually. I just wished I could've put them into the event log, since that's a more obvious place where a sysadmin could see that something was wrong. It would've taken too much time to set that up. In the MFC project I was on the customer wanted to install it such that limited account users could run it. This was more of a challenge than I thought, because the app. was designed to set and get its configuration data to/from the registry. I tried diverting this functionality to a plain text file, but this was problematic as well, since they wanted to install the app. under Program Files, which had Admin-only privileges. I managed to configure the installer to change the write permission for the app. folder where they installed the app. so it could read from and write to its own file in its directory. What I realized a few months later was I probably should have stored the config file in the [user account]/Application Data directory, like I discovered other applications do. A big part of this I think is retraining developers to work within the confines of the sandbox environment. Windows developers have had free reign all this time. A lot of them don't know any better. I brought this up with a Microsoft rep. at a recent user group meeting. I haven't totally looked into this yet, but it appeared she didn't know what I was talking about. Paul Murphy over at ZDNet has been saying that UAC is going to bite Microsoft in the butt. The real culprit in most cases is going to be legacy software that was designed with the idea of almost total access to the system. It's interesting you say that in the Unix world sudo is increasingly being used. Why is that? When I was developing for Unix almost 10 years ago I needed to use su on a few occasions, but it wasn't excessive.

Justin James
Justin James

Mike - I just received the latest issue of MSDN Magazine in the mail today, and this exact topic is actually one of the cover stories. I have not read the article yet, so I cannot vouch for its quality (I literally got the magazine 5 minutes before I read your post). It does not look like the issue that just hit my mailbox has been posted online yet, but check their Web site in a few days (http://msdn.microsoft.com/msdnmag/default.aspx) and you should see the January 2007 issue come up there soon, with the article ("Least Privilege: Teach Your Apps to Play Nicely With Windows Vista User Account Control"). Even though the article is about Windows Vista, if your application works well with UAC, it should also work nicely with XP for non-Admin users. Generally speaking, UAC is actually easier for limited users than XP's system, because at least now limited users have the ability to do things that they could not do before. Where the real pain comes into play is that in Vista, users are limited *by default* and that even admin users have to verify a number of operations, as opposed to XP where users were Admin by default, and Admins had full, non-verified control. If you do not have a subscription to MSDN Magazine, and are a Windows developer, you should try to get a subscription. It comes frww with a MSDN membership, and if you do not have an MSDN membership, you can subscribe to it at http://msdn.microsoft.com/msdnmag/subscribe.aspx It is an extremely valuable resource, "straight from the horse's mouth" on programming for Windows. J.Ja

Justin James
Justin James

Jaqui, UNIX is hardly "convenient". Having to use sudo or su all of the time not really not fun; the alternative to it is to be pretty locked down and not to do too much, or just be running as root. J.Ja

georgeou
georgeou

"The real culprit in most cases is going to be legacy software that was designed with the idea of almost total access to the system." Vista handles this with a mechanism called "shimming". It lies to the legacy applications and let them THINK they're making system level modifications to file and registry when in fact they're only modifying temporary keys and files. This lets the legacy apps work as is without giving them keys to the kingdom.

Justin James
Justin James

Mark, your ressponses always cover so many topics, I can never think of a good title to my replies. :) "I'm a bit confused when you say that users cannot make files whenever they want. Could you go in more detail? I've seen this with the default configuration of limited accounts on XP. I would get file access to a couple of places, like My Documents, but nowhere else really, unless I explicitly changed permissions on a folder as Admin. Unix user accounts have been like this for a long time. Your account directory in Unix is like the My Documents folder on Windows." That's exactly it. When Windows 2000 brought NTFS to desktop users, all of a sudden, a lot of folks (those running limited accounts, at least), suddenly couldn't start doing whatever they wanted. Vista, by setting users to Limited by default (and even harassing Admin users) puts a real edge on it. For example, I am used to being able to edit the Start Menu for "All Users". In vista, even as an admin, each move requires approval. Annoying, but it is nice to know that it isn't going to be done by malware without at least sign off on my part. "I wanted to find a way to log what was going on with a web service. So I tried accessing the system event log. I found out I couldn't do that without jumping through a lot of hoops. I tried writing log messages out to a file, and realized I couldn't do that either, because the web service was not given permission to create files. I ended up putting the log messages into the one place the web service did have access, into the database, which wasn't bad, actually. I just wished I could've put them into the event log, since that's a more obvious place where a sysadmin could see that something was wrong. It would've taken too much time to set that up." .Net handles Event Log very nicely, in my experience. That aside, I have found that having Web apps log to the database is quite conveneient as well. You can do it in the global.asax file, on the OnError event for the application, while has been good for me. "A big part of this I think is retraining developers to work within the confines of the sandbox environment. Windows developers have had free reign all this time. A lot of them don't know any better." Yup, this is really at the heart of the problem! Bad habits over 20 years, a lot of coders may have to be put out to pasture if they cannot relearn how to write code that contains itself to the current user's personal directories, lays off the registry a bit, and does not need to directly access the system. Then again, too many coders hard code directory paths too. After all, who EVER installs Windows to a drive other than the C drive? ;) "Paul Murphy over at ZDNet has been saying that UAC is going to bite Microsoft in the butt. The real culprit in most cases is going to be legacy software that was designed with the idea of almost total access to the system." Yup. But Paul is indirectly right... people will blame Microsoft, not the ISVs, so at the end of the day, it will be Microsoft who pays the price for other people's poor programming. "It's interesting you say that in the Unix world sudo is increasingly being used. Why is that? When I was developing for Unix almost 10 years ago I needed to use su on a few occasions, but it wasn't excessive." As opposed to people just running as root. I think sudo is just being brought to more people's attention. It used to be that you ran as root to do everything, now people are working with limited accounts and using sudo instead. It's smarter security, really. Developers don't need su/sudo, but sys admins do. I never really needed su/sudo as a developer either, except when I was ignoring good habits and writing a system tha1t no ordinary user could use. J.Ja

Jaqui
Jaqui

that need sudo or su are the IT department, from the end user's perspective, it is convienient. and KDE looks enough like windows XP that they wouldn't realise that they are running linux unless they read the splash screen during startup.

Jaqui
Jaqui

like the dot-file style used by unices for this, every application can make a per usr folder or file to store settings specific to that user, without requiring admin priviledges to do so. when the app is started by a user, it is run as that user's process, so has exactly the same access limits. using the user's directory tree, the app can ccreate temporary files, config files for the user. the only admin privs required are during the install [ if for everyone on the network ] to install into a newtork wide accessable location and add a network wide menu entry for it.

apotheon
apotheon

Distributions like Ubuntu, and sysadmins who think similarly to the Ubuntu core developers, are misusing sudo -- and they're trying to justify it by claiming there's a security benefit. Too bad they're wrong. The way to ensure greater security with privilege separated user accounts is to ensure that you use the unprivileged account for everything you can, and a privileged account (such as root) for everything else. People who should only have access to the unprivileged account should be denied the ability to use su, while those who should have access to the root account should be allowed to use su. In the rare case when someone should be confined to a privilege limited account but should also be able to execute a couple of specific privileged operations (such as altering network configuration) without being given the keys to the city, then sudo should be configured to allow those (and only those) operations to be performed by that user account. Ubuntu doesn't do that. In Ubuntu, you simply cannot log in as, or su to, root. Instead, you have to use sudo. This means that sudo is configured to be wide open, allowing the supposedly limited user account to act as a system-wide root account, using nothing more than the supposedly limited account's password to accomplish whatever it wants. This removes a layer of security from the means of privilege escalation: once you crack a normal, supposedly limited user account, you have the keys to the city. All you need to do then, to accomplish whatever you like, is use sudo. You don't have to progress from there to try to crack the root account as well -- which, hopefully, has a better password than the cracked user account. The sudo command is something that should be reserved for exceptional circumstances, not just applied as a blanket "solution" to the "problem" that free unices use a better security model than MS Windows.

Jaqui
Jaqui

the points apotheon mentioned, I can't disagree with your comments. I'm not saying that unices are perfect, but when they have a good admin team they are secure, convenient and open for the end user's needs. it is unfortunate that MS has gotten so many people to beleive that even a server rquires a gui to be effective, but that is the underlying cause of the "shake and bake" admins attitudes.

Justin James
Justin James

"Not entirely true -- the idea is that someone trusted enough to be given the root password is trustworthy enough to not screw stuff up by making dangerous decisions outside the range of his/her knowledge. It is for the in-between cases that sudo was invented, for the purpose of allowing root-privilege access to only specific operations that are necessary for a given person's job." This unfortunately requires a LOT of work on the part of the sysadmins to set this up. Convenience always trumps security for 85%+ of users. The other 15% choose convenience over security 85% of the time. It is a reality. Would you drive a car that would not go in reverse if it detected an object behind you unless you exited the car and verified that no kids were behind it? Probably not. But one that beeped would be OK, but we would quickly learn to ignore the beeps, and we would still have kids run over by people driving in reverse. I am *not* disagreeing with your premise in the slightest, I just think that you do not realise how much Joe Six Pack (as opposed to you or me or Jaqui or George) does not understand about systems. J.Ja

apotheon
apotheon

"[i]Home/snall office users *are* their own IT shop. The sudo/su system, like Vista's UAC is a royal pain in the butt for these users.[/i]" I find su to be absurdly easy to use. For one thing, it's quite rare that it's needed, since the only things that actually require root access are things that affect the state of the underlying system. Running all your userland programs, development and testing, and general networking activities can be run without root privileges. Unices are not like MS Windows, in that you don't need administrative access for stupid crap like playing a computer game or setting up your development environment. In fact, you don't even necessarily need root access to install software, as long as you install it in your own user directory. Using sudo for all administrative functionality can be pretty aggravating after a while, but it's still less annoying than the MS Windows "secure" approach -- just prefix "sudo" on every administrative command from the shell, and you're golden. There's none of this "click OK seven times to execute that command" crap. Using sudo for everything is a suboptimal decision, anyway, and anyone who does so is misusing sudo. "[i]Because the UNIX su/sudo security model only works as long as the end users are able to accomplish 100% of their needs (including restarting unresponsive daemons if those daemons are critical to their job).[/i]" That's only a problem when you misuse sudo or, alternatively, don't use it when you should. See my remarks about misusing sudo further up the discussion. "[i]Just as I am down on the shake-n-bake programmers, the shake-n-bake sys admins create disturbingly insecure systems, regardless of the OS in place.[/i]" I'll certainly agree with that -- and Ubuntu is the distro of choice for shake-n-bake sysadmins. "[i]One of the dangers of UNIX has always been that root is assumed to be omniscient, and therefore the fact that root is omnipotent is not a risk. This is baloney, and smart guys like you know it.[/i]" Not entirely true -- the idea is that someone trusted enough to be given the root password is trustworthy enough to not screw stuff up by making dangerous decisions outside the range of his/her knowledge. It is for the in-between cases that sudo was invented, for the purpose of allowing root-privilege access to only specific operations that are necessary for a given person's job.

Justin James
Justin James

Jaqui - You are 100% correct; in a well managed UNIX shop, standard users almost never actually need su/sudo. However. * Home/snall office users *are* their own IT shop. The sudo/su system, like Vista's UAC is a royal pain in the butt for these users. And as always, the smaller, less knowledgable companies (think of the 10 person company) has the triple whammy of no IT department, less-than-knowledgable users, and a lack of IT budget to put things like firewalls, gateway virus scanners, etc. into place. These are the shops where "security" is a password P-Touch'ed to the server's monitor, everyone running a different version of the OS, no patching occuring, and a copy of Symantec Internet Security Suite on half of the computers (only one of which is getting updated, since they do not have any one in charge of keeping the subscription paid for), and so on. These are the users who are least able to safely run as admin/root, yet due to a lack of IT, they all are running as admin/root, and if not, have admin/root password stuck to their monitor. * IT departments are unresponsive! All too often, internal IT departments suffer the delusion that IT exists for the sake of IT, as opposed to IT existing for the sake of serving users. These are the IT departments where everything requires a call to the help desk, waiting on hold, and 30 day minimum times to implement a change request form. As a result, the moment a single IT person provides an admin/root password to an end user over the course of a phone troubleshooting, that login information spreads like wildfire as the end users hijack the systems. A great example of this was when I was doing network management/monitoring at a NOC. HP OpenView would periodically crash, requiring that the daemon be restarted. Internal IT would not/could not fix the problem, and refused to set up a script with rwx--x--- priviledges that would sudo the restarting of the daemon, which would have been a smart move. They said that was a "security risk." Instead, a few of the high level network analysts had the root password, and would VPN in and SSH to the server to restart the daemon. Still sort of secure, I suppose. One day, the network analyst on duty was nowhere near their laptop, and walked one of the people on the floor through restarting the daemon. Within a few days, all of the floor workers had the root password. Hardly secure. Why? Because the UNIX su/sudo security model only works as long as the end users are able to accomplish 100% of their needs (including restarting unresponsive daemons if those daemons are critical to their job). If IT will not provide instant, 24x7 response on tasks that require su/sudo, the users can and will hijack the box as soon as they can. * Well managed UNIX boxes seem to be getting increasingly rare as a percentage of installed UNIX boxes. Gone are the days where the sys admins were those bearded guys with suspenders, goofy looking hats, and a general hobbit appearance who cut their teeth on punch cards and could write code and admin a system with equal skill, because the two used to be inseparable. Welcome to the world of the folks who got started with Linux with some Knoppix Live CD and are now admin'ing a server. These are the folks using the latest branch of the source tree instead of RELEASE because "I've never had a problem with the dev version of this distro before", admin'ing their systems through KDE or GNOME because "it has pretty colors and bash is SO black and white" and who can't get a file out of a tarball without double clicking to open it and dragging it to the right location. Setting umasks for everyone at full permissions, because messing with chmod and chgrp and chown is SO too much like bash. And they cannot figure out a crontab if the interface does not have EZ Checkboxes for a schedule. These folks scare me. Being a sys admin is so much more than knowing how to install a piece of software on a server and get it up and running. Just as I am down on the shake-n-bake programmers, the shake-n-bake sys admins create disturbingly insecure systems, regardless of the OS in place. * One of the dangers of UNIX has always been that root is assumed to be omniscient, and therefore the fact that root is omnipotent is not a risk. This is baloney, and smart guys like you know it. Example: at my college (this came second hand to me, so its veracity cannot be verified, but I beleive it), a gentleman had placed a file in the /tmp directory named "do_not_run_me". It's contents? "chmod 000 -R /" Some blithering idiot of a sys admin, running as root while on a periodic clean out of /tmp, ran it without actually inspecting it first. The entire computer science cluster was down for days as a result. Likewise, who *hasn't* run "rm -R /*" by accident instead of "rm -R ./*" or run "rm -R *" without noticing that the cd command above it had failed due to a typo? Even in Windows and GUI directory tools, it is not unheard of to accidentally delete the wrong things, over a network share where the recycle bin does not apply. Even the su/sudo approach is not infallable. I am not implying that there is some magic system of perfection out there, but I am saying that su/sudo is deliberately painful to use, to help prevent mistakes from happening. In short, it is a speed bump, and thus, inconvenient. J.Ja

Justin James
Justin James

When everyone can sudo, it is just a formality, like everyone just clicking "yes" to every dialog box that pops up in Windows. When a user automatically prefixes everything with sudo by default to make things more convenient, security is gone. And that is, more or less, my point. J.Ja