Joanna Rutkowska has always been a big supporter of the Windows Vista security model. Until she stumbled upon a ‘very severe hole’ in the design of UAC and found out – from Microsoft officials – that the default no-admin setting isn’t even a security mechanism anymore. Rutkowska believes UAC has a major flaw in the way it automatically assumes that all setup programs (application installers) should be run with administrator privileges.
Vista has ways to redirect changes to protected registry values and files to user-specific locations to support legacy apps. Why not do that with installers? You could then just choose to apply the changes to the protected areas later, as you wish.
Because the installers are also likely to put things into system library areas.
To save the reader some time, Joanna R. was not really upset about Installation programs running as Admin, but about flaws in the design of UAC not being labeled as security violations but “design decisions”. For instance, there were ways a lower-privileged process could gain access to higher-privilege due to “design tradeoffs”. She felt they should still be bugs.
It is not surprising that Setup programs have to run with Admin privilege. I have to install my RPM’s or Deb’s as superuser. Otherwise, I do not have access to the package database. Similar reasoning is true for Windows installations. That should make you more aware of installing the cool Tetris game you downloaded. Also, you should be wary of installing RPMs and DEBs from untrusted sources.
Is there such a thing as a “user-level” RPM? Sounds like it would be a good idea to separate System installs from User installs, and still use the same installation mechanism, whether it be RPM, Deb, or Windows Installer.
If you know what you’re doing, rpm files can certainly be installed without admin privileges, to your home directory, or where ever. You may run into dependency problems of course, but like I say, it’s not so bad if you know what you’re doing.
At any rate, Windows installers are more akin to something like the Loki installer under Linux. There’s absolutely no reason in my eyes why something like that would require admin priviliges. It’s just silly programmers that don’t know what they’re doing is all. Or perhaps they know exactly what they’re doing (think spyware etc).
Windows installers are more akin to something like the Loki installer under Linux
I disagree. Windows installs now use the MSI framework, they are not just “copying programs” like in the early setup days. By interacting with the MSI framwork, they do interact with the MSI windows installtion database [E.g., Add/Remove Programs], and as such they are very similar to Linux installs.
However, I do think they “could” be done in a way that they would not need admin privileges, but that is a future task.
When I try to install an RPM, it complains about not having permission to interact with the RPM database. Am I missing something?
When I try to install an RPM, it complains about not having permission to interact with the RPM database. Am I missing something?
That’s correct AFAIK, the rpm db is restricted. You can extract an rpm as a user and manually install it, but then it may as well be a .tar file.
Suse/Novell tried to work around this to a certain extent with the ill-fated zmd framework; it used dbus to allow an updater application running under regular user permissions to signal the package management daemon to selectively download and install signed updates, which effectively worked around the rpm permission issues without requiring the actual user to authenticate as root. And it was possibly the single intelligent idea within zmd, for which everything else was horribly, horribly wrong.
Warning: tangential rant follows…
And it was possibly the single intelligent idea within zmd, for which everything else was horribly, horribly wrong.
I was one of the QA team working on ZENworks Linux Management 7, which is the product zmd was originally created for. zmd is essentially a rewrite of rcd, the Red Carpet Daemon, which was part of Ximian’s Red Carpet Enterprise. The reason zmd and rcd needed to run as daemons is to enable system administrators to remotely manage the packages installed on the system (which is the primary selling point of RCE and ZENworks), and because RPM typically requires root privileges, those daemons ran as root. The fact that this allows normal users to do limited package management operations (as decided by the administrator) is a nice side effect of that.
The issues I believe you’re referring to in zmd aren’t exactly zmd’s fault. zmd, as shipped in ZENworks, is relatively stable, fast, and reliable. But that’s not the version of zmd most people saw.
See, zmd has a concept of “backends”. The backend is essentially an abstraction layer around the underlying package management system. Backends handle package management tasks as well as doing dependency resultion. The backend that zmd shipped with in ZENworks is heavily based on libredcarpet, the old standby from Red Carpet Enterprise, and it works pretty well. However, SuSE Linux doesn’t just consist of packages. It also has a concept of “patches”, “patterns”, and “products”, which are meant to allow, among other things, for the vendor (Novell) to release operating system patches that do things other than just update a package (say, run a script, or display a EULA).
To allow for these new concepts, SuSE wrote a new package management library called libzypp, which contains its own dependency resolver and handles package management in its own way. This was entirely new code written for the release of OpenSUSE 10.0 and SLED/SLES 10. Unfortunately, libzypp doesn’t exactly snap neatly into zmd. For an idea of what I’m talking about, see http://en.opensuse.org/Understanding_zmd , which contains a diagram I drew awhile back to explain the whole thing.
IIRC, if you don’t care about patches/patterns/products (and I think most casual Linux users probably don’t), it’s still possible to install the libredcarpet backend, which will speed up zmd at least tenfold, along with other reliability benefits. I’m not sure who maintains the RPMs for that these days, but Google may be able to provide some clues.
Fair enough, but it sort of underscores that zmd should not have been forklifted into Suse 10.1, and it was kind of clear that the decision to break version freeze during the beta phase in order to force it in came from the parent company for what I assume was to ensure testing before it was implemented into SLED 10.
I don’t want to take away from the capability of Zenworks, and in fairness from what I’ve heard it was much more effective in SLED, which makes sense given the environment SLED was targeted for.
It was just a bad decision, and a poorly executed one, to put it into Suse, particularly since it offered no tangible benefits to anyone but Novell; I could live with that, given Novell’s sponsorship of Suse, but not at the cost that was extracted in terms of useability and reputation for a solid, well founded distribution.
I wouldn’t consider your post to be a rant, it’s actually one of the most intelligent explanations for zmd and the reasoning behind it; and given the way zmd has been mercilessly slagged by the community (myself included) I can understand your desire to respond. But I still think it was a horrible decision that struck a black mark on Suse that exists to this day, though they’ve announced they’re pulling it altogether for 10.3 I understand.
That doesn’t take away from what it offers a Zenworks-managed infrastructure, just underscores the importance of using the right tool for the right job.
Totally agree. I don’t know how many customers out there are actually using zmd’s remote-management features (I don’t have access to that information because I don’t work for Novell anymore).
Part of the rationale behind the decision was that Novell shouldn’t have 2 entirely separate package management systems, so for the purposes of code sharing, it would be good to consolidate them. I think a lot of what undermined that effort had to do with multiple groups all running in separate directions at once, and different people in the company having different ideas of what package management best-practices actually are.
Personally, I have somewhat of a problem with the concept that “patches” are somehow different from regular RPMs – Red Hat and Debian both distribute software updates as plain old packages, and it works fine for them. But there are certainly arguments for why the use cases for them are different – I just disagree with the idea that the differences are so strong that they necessitate creating a whole new package management system (ZYPP) to sit on top of/replace a perfectly decent package management system (RPM). And like I said in the last post, zmd without libzypp works just fine.
However, I do think they “could” be done in a way that they would not need admin privileges, but that is a future task.
This is already possible using Windows Installer 4.0 and (preferably) ClickOnce, but the application developer needs to design the application and deployment package so it doesn’t impact the system (ClickOnce is specifically designed for this scenario).
There’s already a Tetris game online by Chris Sells that uses ClickOnce and should install (w/ Start Menu and A/RP entries) as standard user. It was orriginally written in 2002 for .NET 1.x, then updated for ClickOnce while that was in development.
Main page
http://www.sellsbrothers.com/wahoo/
ClickOnce link:
http://www.sellsbrothers.com/wahoo2/publish.htm
Edited 2007-02-14 22:30
Excellent!
There must not be any Shared Assemblies needed (GAC), or major dependencies.
Edited 2007-02-14 22:33
Is there such a thing as a “user-level” RPM? Sounds like it would be a good idea to separate System installs from User installs, and still use the same installation mechanism, whether it be RPM, Deb, or Windows Installer.
That’s not exactly it, but Klik’s compressed images are similar to what you’re talking about (see the article on Klik on OSNews today). All Klik apps are “installed” as a normal user.
RPM is just one of many after-the-fact package managers that necessarily have their own idea about where files belong, and those directories belong to root. But you’re talking about an OS with Unix design. You can acquire the fileset for an app by whatever means the internet offers, or build the source right in your home directory, then just put the files where you want them and update your PATH. With OS X, the same level of isolation is offered with one click and drop. Put the .app bundle wherever you’re allowed to put it, and when you run it, it’ll store its own files in its own directory in your User folder. There is no reason to allow a simple app to touch the system.
With Windows, most software is distributed exclusively as an executable installer. The way UAC is set to work, Vista is eager to give the aforementioned “most software” control over the system. It’s either allow for that or don’t use the file you downloaded at all, an unlikely choice in most cases.
The fundamental insecurity of computers in general and operating systems in particular is worth bringing up, but the fundamental insecurity of a five-year, multi-billion dollar security system project is a class all its own.
Seems like a change that should have made it into the release notes. Seems to be some difference of opinion on what constitutes security stemming from not knowing what exactly the design of Vista, assuming that it actually has one, is and who or what it’s targeted for. Maybe she has the wrong version, quite some confusion there.
Microsoft will not be concerned about this “feature” until someone learns to exploit it. They are very good at addressing things after they become a problem.
She’s making a big deal out of her misunderstanding of the purpose of UAC. If you run a program under UAC, it is on your desktop after it launches and is accessible to other programs through normal Window Management functions. This is true, AFAIK, in X11 as well. Two programs on a graphical desktop are not really shielded from sending each other messages and doing other nasty “shatter” style attacks.
UAC doesn’t prevent this and is not designed to do so. It’s only a mechanism to allow someone to quickly switch from standard-user privileges to higher privileges. That’s the main power of UAC: it makes it tolerable for Windows users to run as non-admins.
I don’t think she “is just trying to get fame”…she is fairly well known already ( http://www.eweek.com/article2/0,1895,2078362,00.asp ).
“UAC doesn’t prevent this and is not designed to do so. It’s only a mechanism to allow someone to quickly switch from standard-user privileges to higher privileges. That’s the main power of UAC: it makes it tolerable for Windows users to run as non-admins.”
And I think UAC is supposed to be more than just a substitute for “RunAs”.
This is pretty typical of Microsoft general approach to security in Vista, and I can’t say I blame them really.
Users are going to balk at UAC, even in its current over-simplified state. Having worked for 3 years on a helpdesk, I’m here to tell you that the average user does not know, or want to know about any of this.
They will simply press the button that they know always works (i.e The “Run as Administrator” button).
If Microsoft adds any more complexity to the UAC, they are going to alienate their customer base.
It’s a similar story with the Windows Firewall …
I use XP for most of my work and i install a lot of program running under a normal user account. Many installer just works fine even if they are running under normal user.
This makes me feel safe when i am trying to install an untrusted application. If Vista forces user to run the setup as Admin only then i would say it is a bad design and a step backward IMHO.
The normal user account in XP is running with administrator rights
Running as normal user in XP (e.g. Restricted User / Limited User) makes it virtually impossible to install applications.
If you try to run an installer in Win2K, XP og Win2K3 Server you’ll receive a Run As-prompt so you can run the installer as Administrator. Or you may be notified that you have to run the installer as Administrator. Clicking “OK” will cancel installation. Now you can right click and choose “Run As…”
Even as Power User (Standard User) with extended rights you will often be prompted to run as Administrator or be notified of lacking permissions.
Most Windows applications cannot be installed with anything but Administrator rights. Most however can run without Administrator rights, and it shouldn’t be much problem creating a framework allowing for Program Installations in the users homefolder (“Users” in Vista – “Documents And Settings” in Win2K, XP, Win2K3 Server).
Woooo, I wish most applications could run in regular user accounts. I would not be pullin my hair out with this on going project we have here where I work.
I work for the US federal government and at the agency I work for they made a mandate that ALL machines on the network had to ether: 1. Be without admin privlages or 2. Users had to move to a development network (Where they could have FULL admin privileges but had limited access to the production network.)
Because there are so many applications (Like Oracle and Remedy) that could not run properly without admin privileges or modified folders that 100 out of the 250 users we have had to move to the development network. It was and is a mess.
A lot of applications need access to C: and also temp folders, files. Ability to change ODBC, reg settings, and TNS Names files on C:
Also things like IIS for development and MS SQL, visual studio can NOT be run without admin privileges (Windows XP and 2000 pro) This problem alone too 50 of our developers off the network, right off the top. š
I understand that developers should be working in a development emviorment but to be locked and blocked off the rest of the network is crazy. LOL!
Edit:
Oh and we have Linux and Mac developers and users. Long as their machines are patched and don’t come up on the IDS security reports, they don’t have to be put on the developers network. (And right now I am using eComStation on the production network.)
Edited 2007-02-15 14:15
This looks just like the story I submitted….oh wait it IS the exact same story I submitted. Guess I wont make that mistake again.