Slashdot Mirror
Coding Around UAC's Security Limitations
Mariam writes "Free software developers from the non-profit NeoSmart Technologies have published a report detailing their experience with coding around Windows Vista's UAC limitations, including the steps they took to make their software perform system actions without requiring admin approval or UAC elevation. Their conclusion? That Windows Vista's improved security model is nothing more than a series of obstacles that in reality only make it more difficult for honest ISVs to publish working code and not actually providing any true protection from malware authors. Quoting from the post: 'Perhaps most importantly though, is the fact that Windows Vista's newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security. Any program that UAC blocks from starting up "for good security reasons" can be coded to work around these limitations with (relative) ease. The "architectural redesign" of Vista's security framework isn't so much a rebuilt system as much as it is a makeover, intended to give the false impression of a more secure OS.'"
Sounds like it was written by Homeland Security and the TSA.
It must have been something you assimilated. . . .
I think I am going to have a heart attack from NOT being surprised!
So, apart from DRM, what has Microsoft actually created new in Vista? looks like a lot of people have spent 5 years hanging around the water cooler.
Damn, on further consideration, the quote should have been: I think I'm gonna have a heart attack and die from not surprise!
Basically, all they had to do is split the thing into a front-end "userspace client" and a back-end "service".
Gee, sounds like a daemon that can be controlled from an application to me.
Some clever programmers found a way to force a Vista PC to obey a user with admin rights.
I'm sure there will be a patch to fix this glaring security hole in the next batch of updates.
Help stamp out iliturcy.
Much as I like seeing Microsoft humbled, the comments on the original article seem to exonerate Microsoft of being as stupid as the article makes them sound. Lazy, perhaps, but not that stupid.
The article uses a play out of Microsoft's playbook for Vista compatibility -- break an application that requires admin privileges into two parts: a privileged service and an unprivileged UI. Nothing to see here, move along.
The "bottom line" starts off saying it wasn't easy, took much additional code, and many man hours of work. Then the next paragraph tells you it's "easy to code around".
This is the problem with Blogs. It looks like journalism, but it isn't.
If and when Microsoft closes those loopholes, any software that abuses them will break.
On the plus side, it's another reason for customers to buy the next version of your software...
Hmmmm, would a ISV make more money overall by deliberatly NOT being forwards compatible? are some intentionally breaking the bounds of the published SDK for this reason?
I was under the impression that Microsoft wants developers to rework their code to use calls that don't require security elevation. The fact that performing these workarounds is "easy" sounds to be a good thing. After all, why would you want developers to have trouble adopting a new standard?
I care about security. A lot. I do my banking on my home PC and any kind of fraud or identity theft has the potential to make my life hell. Still, not only do I not run Vista (except on a laptop which it came pre-installed on and which I dual boot with XP as default) but the first thing I do is turn UAC off. It's not just painful, it's no more secure than putting 100 locks on your front door. Burgulars and home invaders can still kick the fucking thing down, only now it takes you an hour to get into your own home. Microsoft has lost the plot in recent years. Changes to Office, a dud version of windows with almost nothing new and lots of DRM shite, changes to poiicy in everything from OS to Office to gaming. None of it friendly to the end user. They're large enough that the jury's out as to whether they'll sustain the hit or go down but they're making their systems undesirable to work with.
These posts express my own personal views, not those of my employer
So he created a service that runs with the necessary privileges to do what it needs, which communicates with a non-privileged front-end, and which requires privileges to install.
How is this a "hack"?
Perhaps the author of iReboot didn't see the rational for isolating a piece of code that needs to do something privileged and having it install and run in a user account which has sufficient permissions to allow it to run--but from a security standpoint this is no different than in Linux, where privileged code runs in a separate account from the user, and where IPC is used to communicate with that process.
I hope they're not going to try to patent the method - I used a similar method to get around a setuid() problem (whereby dropping a setuid program into the local uid meant it was unable to regain the "elevated", setuid, privilege again) in version 2.4 of a program I released on 20/06/1990: I fork()ed off a server process before dropping the uid of the process to that of the real user.
One of our recent projects involved hosting a .NET control in Internet Explorer as part of an Intranet page for editing and uploading photos. The control worked fine, and we were able to manage security permissions such that it could access the files it needed to (and even delete them after as desired - it has full trust).
.NET control and the surrounding page (you can't, for example, just call a function on the page, despite the fact that you have full trust).
The problem was that we wanted the page to refresh after the upload was complete. This seems like it should be fairly simple, but with how the security works, there's not a simple way to communicate between the
With that being the case, I tried editing a property on the control once it was finished uploading, but that too didn't work as the page couldn't read them (even properties like "height" that it could infer couldn't be read directly). I thought about some fairly complicated solutions involving polling using XMLHTTP, partial refreshes or scripting or something - but what I ended up doing was this:
1. When the page loads, take note of the position of two elements on the page.
2. Poll the position of these elements a few times each second.
3. When the upload control finishes, it increases its height by 4 or 5 pixels.
4. This displaces the other elements on the page, and this can be used as a signal that an upload is complete and a refresh should be done.
This ended up working fine, but I felt ridiculous for having done it this way. There's no security being added here - the control and the page can communicate all they want via the server or scripting (or 100 other ways), it just means that using the controls is much more difficult and obscure than it needs to be.
Let's not stir that bag of worms...
So they created a service (daemon) that exposed a interface that had no ACL on it that allowed the caller to perform privliged opperations, they had the administrator (root) install the service and grant it administrative permissions (again, root) and then had a unprivliged application call that interface. Sounds exactly like unix to me, more over short of not having ACLs on the interface, Microsoft has white papers telling folks how to do just this. In fact a CS major would know this as "least-privliged-design" oh-no mr. bill. Only on Slashdot would this qualify as news.
I'm sorry but their "bypass" was to create a service running in an elevated state and then communicate with said service via exposed APIs.
I fail to see how they drew this conclusion:
"[UAC does] not actually providing any true protection from malware authors"
This isn't a hole in the system. If applications couldn't use services running at admin or system then the entire system would be damn near nonfunctional.
I mean how would you even play music without a regular application being able to communicate up safely to the driver?
The article is fine. The person who wrote the summary didn't actually RTFA and is just trolling. They haven't justified anything they've said.
It's a lot easier to make an isolated service with rigidly defined IPC secure than it is to make something that interacts directly with the user secure.
But maybe it's all that unix poisoning my brain.
Are you sure M$ didn't outsource the creation of their "for your own protection" vista security model to the Department of Hopeless Stupidity?
Hummm, looks impressive, costs you time and energy, can be circumvented easily and accomplishes nothing useful- yup thats security designed to be DHS compliant.
So the user is asked to install the service with full priv's, and then this service has.... full priv's? And this is a workaround?
Waste of space, move on... nothing to see here.
They got "around" UAC by creating a service that runs as a privileged account (default Windows services do the *exact* same thing already and so do many other 3rd party apps) with a UI which provides users the ability to communicate with that service. Exactly how is that getting around UAC? If you don't use a privileged service then you basically can't do anything that requires privileges so isn't this what the design is supposed to be to properly interact with UAC? Or am I missing something? Maybe these guys were just too used to coding up anything they wanted to get something working and now they have to do it more securely (and properly for that matter by splitting up their logic) and are just a little annoyed they had to spend some extra time doing it. Tons of other applications already do this so it is nothing new. Looks to me like they are doing exactly what they should be doing.
this nation, under God, shall have a new birth of freedom. -- Lincoln, Gettysburg Address
The "architectural redesign" of Vista's security framework isn't so much a rebuilt system as much as it is a makeover, intended to give the false impression of a more secure OS.
Ouch.
The higher the technology, the sharper that two-edged sword.
With respect to the iReboot team (who seem to have written a pretty nifty piece of software and certainly know their way around programming), there is so much spin on this article that light passing near it bends.
The "Gory details" portion of the article gives a pretty good explanation of the work they had to do to make iReboot access high-permission OS features via a low-permission client. I have no idea how they got from there to "Any program that UAC blocks from starting up 'for good security reasons' can be coded to work around these limitations with (relative) ease." What they seem to be missing is that there was an installer in the loop---an installer that requires admin privileges. This is exactly the part of the process that UAC is trying to force upon Windows developers!
The most significant problems with the Windows XP security model are as much social as technical. Because the model didn't make it easy to get "serious work" done as a non-administrator, most people are running as administrators most of the time. This creates a whole culture that is very vulnerable to social engineering---simple games are being run at the same permission level as complex drive-recovery utilities and keyboard loggers.
By having people run low-privilege by default and escalating when necessary, the UAC model forces developers to be a little clearer about what their applications are doing (since things that "just worked" in WinXP now require permission in Vista). My understanding is that the way iReboot works now is the way it should always have worked, under the Windows OS model; the fact that it also worked if the user were running as an administrator was a happy accident. How well did the old iReboot work if I wasn't running as an administrator? If the answer is "It didn't," then, well, maybe they were doing it wrong the whole time.
UAC has some problems, but the fact that it puts more work on developers isn't one of them. The work is necessary because it is accounting for a weaker security model from the past. And developers should know that security isn't free.
Take care,
Mark
There is a solution...
That's the way it's supposed to work. You install a service that gets the heavy lifting done without requiring UAC prompts while a small user-mode application interacts with the service. You still get a UAC prompt when installing the service, so this is a non-issue.
"...is the fact that Windows Vista's newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security"
So that would make Vista's UAC the TSA of software security? (for the non-USians, TSA are the friendly folks who have us remove our shoes at airport security checkpoints, and require us to package all carryon liquids in 3 ounce containers in clear plastic baggies, among other acts of security theater)
Remain calm! All is well!
In defense of Vista (never thought I'd write that!) It's my understanding that UAC is actually aimed at developers. There's a large ecosystem of Windows developers of varying quality, and Microsoft wanted to force them to write programs that behave correctly. Developers who were used to doing all sorts of system-level actions without considering security now have to contend with an inconvenient UAC warning, so they're forced (at least nominally) to try and find a way to do things within userspace as much as possible.
In all matters of opinion, our adversaries are insane. -Oscar Wilde
a programmer is bitter that an OS forced him to separate privileged code from unprivileged. news at 11.
http://blogs.msdn.com/oldnewthing/archive/2007/08/07/4268706.aspx
The big take away here is that this is not a security hole in any sense of the word. In order for a malware author to exploit this they would first have to get the user to install a service on the machine. If you can get the user to install random software, why bother with any other steps? You've already compromised the machine. I mean if your "security hack" involves the step "Get user to install malicious software", then you don't have a security hole, you have stupid users.
My twitter
You mean there is an easy way to code around those annoying Windows Vista privilege escalation dialog boxes??? Thanks god!!!
So to "get around" the Vista security they had to install a service using admin privileges. Ok????
Well... serves them right for missing the point completely.
...) which is then accessed by unprivileged (userland) interfaces. If they worked around anything, it was basically just their own stupidity. Why do they blame some security put in place to prevent them from making the stupidity in the first place.
1) Not everybody runs as and Administrator. There are people that are savvy about their computers AND their security - i.e. not running as Administrators and, gasp, possibly even using dual-boot.
2) If you make application that simply assumes that everybody runs as and Administrator and cry foul when suddenly your favorite OS provider comes to senses and makes you stop doing that, then you're simply a bad programmer. Bad, bad programmer.
3) Wow... what a concept: you make a privileged system component (device driver, service, daemon,
4) If they think they're high-tech, then they should look around. UNIX had been doing the same since at least '90s, after suddenly realizing that SUID root isn't always a good thing.
5) Maybe they should find something else to do. Your average Indian does better job than they ever thought possible.
It took a bad ass marine with a bunch of serious weaponry to fix it again.
If my call is important, why am I talking to a recording?
Microsoft has said that UAC is meant to be annoying to force developers to do things properly to avoid it.
Sounds like they're just doing things more on the proper side. I'm sure Vista isn't that secure but at least they've made some sort of effort even if it's poorly thought out.
Rather than have UAC come up and have the user simply ok anything that comes up. They should have stopped the program from running at all. Developers can just rely on users clicking ok because, as annoyed as they may get, most won't switch to Linux or even Mac. So where is the incentive not to annoy the customer?
This is the United Aerospace Corp that runs those waste dumps around mars right - are they having security problems again? will they never learn?
Does it really make sense to spend so much talking about how big of a pain it makes coding for programmer, but then point out how easy it is for malware to get around it? Something about that just doesn't quite make sense.
Mod parent insightful.
BTW1 when I installed Microsoft Visual C++ 2003 on Vista it makes me explicitly start it in Administrator mode. That should tell you the design of UAC is broken.
BTW2 Given a choice between rewriting our apps for the latest version of Windows just to support the retarded Vista designers, or rewriting it for the web aka Google apps, guess which one I'd choose?
I don't think the certificate lasts more than a year at a time either. Anyone writing free utilities that need privs isnt' going to want to spend several hundred $ a year to "certify" their sw...
This issue is a bit more complicated than you think.
Wanting to use VLC as my default player in Vista, UAC always prompted
.sdb file to the Vista computer you want to alter the elevation prompt behavior on.
.SDB file as abc.sdb in the c:\Windows folder, the command should be like this:
me to Allow or Deny - I couldn't get around it.
I don't want to turn off UAC as this is the wife's computer.
Some research brought me to: http://www.winvistaclub.com/f6.html
With this info:
---
1) Download and install the Microsoft Application Compatibility Toolkit 5.0.
( http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E-492DD6DA2971&displaylang=en#filelist )
2) In the Start menu, locate the new folder. Find the shortcut icon for Compatibility Administrator. Right click it and clik Run as administrator.
3) In the left hand pane, right-click on the database under Custom Databases and select Create New, and select Application Fix.
4) Enter the name and other details of the application you want to alter behavior on and then browse to it to select it. Click Next.
5) Click Next until you are in the Compatibility Fixes screen.
6) On the Compatibility Fixes screen, find the item RunAsInvoker, and check it.
7) Click Next and then Finish.
8) Select File and Save As. Save the file as a filename.SDB type file in a directory you will easily find it.
9) Copy the
10) Click Start>All Programs>Accessories. Right click Command Prompt and click Run as administrator.
11) Run the command below:
sdbinst \.sdb
For example, if you saved the
sdbinst c:\windows\abc.sdb
It should prompt: Installation of complete.
---
Now VLC is my default player w/o having to annoy me.
This is how MS recommends you do it! Suppose you have something like a virus scanner. You need to have admin access to perform some of your tasks. Also, you should be running at all times in the background, not just when a user is logged in. Well this mean you don't want to just run as a program that ask for admin. This is problematic because it'll get annoying to the user (since it'll ask on every login) and since that if no user is logged in, virus protection is inactive.
The right answer, and the answer that the AV solutions I've looked at take, is to have a service that does the actual work, and then have a non-privileged client that the user gets at to control it. That way the virus scanner can do its job regardless of user status, and not have to bug the user with elevation requests when ti runs or scans and so on.
This is additionally necessary in Vista when dealing with services since services can't interact with the desktop anymore to prevent shatter attacks. So you need to have two separate processes: One that is the privileged service, the other that is the deprivileged UI.
So all they seem to have discovered here is that you can control privileged services with deprivileged processes... Which is precisely how it was intended.
What the site describes in neither a loop hole nor a work around: :) )
1. This is the _PROPER_ and documented way to add elevated applications
2. Adding such applications can not happen _WITHOUT_ the permission of an administrator (the installer in their case)
3. This is the same in Linux/Unix (For all Linux/Unix lovers
So don't blame UAC for being insecure - which it is not.
The only annoying feature in programming UAC is that you cant elevate from within a program. You either need to start the program with elevated rights (using a manifest) or use elevated COM components (which is more or less the programmatic way).
If you are annoyed by the frequent prompts - you can enable auto elevation using the security policy editor. UAC + auto elevation is still much more secure than UAC turned off.
BTW, Ubuntu has pretty much the same behaviour
I'm sorry, but Microsoft does NOT sell UAC as a "security framework" or a "security model" or even a security boundary, as the article claims. It's a convenience tool that makes it easier for you to run applications as standard user, that's IT. Anyone that claims UAC has ANYTHING to do with security has absolutely no clue what they're talking about -- and I challenge you to show me Microsoft documentation that speaks of UAC as a security boundary.
From TFA: "Microsoft can claim that Vista blocks system-modification tools from running at startup;" -- again, I'm sorry, but Microsoft does not make this claim. The steps that the developers of this product (admittedly a good one) are perfectly in line with what I'd expect a system of this nature to do: run as a service. That's *exactly* what services are supposed to be: administrative-level daemons that must launch on startup and are independent of the user account (or always require high privileges). Microsoft does not block applications requiring admin access from starting up for SECURITY -- it's done because otherwise, your computer would be stuck on the secure desktop waiting for authorization, and anyone possibly depending on the application (and anyone else also requiring elevation -- AFAIK, the AppInfo service can only request one elevation at a time) would also be frozen.
I don't see what the big deal is. I run OS X on my desktop and I see plenty of similar applications running as services, in fact, I'm pretty sure Apple's guidelines also don't allow for applications that require root access to prompt for credentials during the startup process. It's just bad user experience.
It's called "root4everybody". It's a daemon that installs on your Linux box. It opens a socket and accepts text commands on that socket, and then executes them.
The beauty of it is that it gets around the limitations of UAC, er, I mean the inconvenience of not having root access. Ordinary users can send their commands to the socket, and the root4everybody daemon will execute these commands as the root user for you. No sudo! No su! No root login! It's so convenient!
Plus, it's web enabled. It automatically opens the port on your firewall to allow anybody on the Internet to access root on the machine. This means that when you are away from your computer you can execute root commands on your computer at home. It's so convenient!
Seriously, can anybody tell me why this way of getting around Vista's UAC is any different from the dumbass scheme I've outlined here?
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
Shouldn't that be || ?
What's your most valuable thing in the system?
.NET/Java to sand boxing every application, but that's not common to sandbox the local application, yet.
Probably the data (documents, emails), or system resource (like CPU and Internet connectivity) for spammer.
Exploiting these require no admin privilege, UAC won't be able to block that. If you just double-click any executable, you are giving full-trust and exposed to this risk. period.
Is Linux, Mac, <Insert your favorite OS name> better protected in this case? I honestly don't think so.
May be you can get away with managed code like
Why the hell do they need to run as admin as the first place? On unix, everyone wants to run its software as non-root and some people even code protection to exit on startup if the user is root. The problem here is not the user, neither UAC, it's the software developers. In order to trigger UAC, they must be doing some funky *wrong* things.
This is just a huge security hole that infects your computer when the software is installed. If they did anything simple as a 'ReadFile' as the privileged user, and that you can trigger the daemon to execute it, then it just compromised your system.
So instead of creating various, new, security issues, just fix your damn software please.
Touche. Got me there. However, you drop privileges after the port binding, otherwise httpd wouldn't run as apache:apache or nobody:nobody on port 80! Sometimes with xinetd and/or tcp/ip wrappers between the two.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Ok, so the original scenario is that the functionality used by iReboot (editing boot configuration data) requires admin or system-level privileges. As an ordinary user, you're not getting these privileges without an UAC prompt on Vista.
What the devs have done is not exactly rocket science: they created a service that exposes some interface towards unprivileged apps to access the formerly UAC-protected functionality (changing the default boot OS in the Vista boot loader).
When they're done highfiving themselves maybe they should pause one sec and think about what they've really done: any app running as an ordinary user can now make a call to their service and muck around with the BCD.
FAIL.
While you're at it guys, why don't you wrap the entire Win32 API in your service and expose it to the user-level apps? No more pesky user access control. Everyone runs as LocalSystem. Hoorray!
What they should have done is simple and their basic idea is right: split the app into two. Have the systray icon run as a regular, unelevated piece of code. When the user selects an OS from the menu that they present, THEN do the elevation (by launching the high-privileged process) and make changes to the BCD. This way you're not exposing anything to the outside world. You also don't have a constantly running service eating up resources. A new process is only launched (and an UAC prompt is presented) when a system change must be made. Simple and clean.
Good point, but, like you said, you drop into a chroot after binding. Also, if you're facing the web, you probably have xinetd and/or tcp/ip wrappers between the firewall and the less privileged service threads. You can even chroot an entire set of services together away from your OS. But, you are correct, you have to be root to start the service, and you can also mirror the port. I think you can even redirect the connection with the 'tc' or 'ip' commands. Anyways, I stand corrected ;).
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
There is no security hole here. It seems to me that UAC is pointless for startup processes because you need UAC in the first place to install them (or at least you should). What MS has done is just dumb and a pita. It should be possible to install a privileged startup process without resorting to such workarounds as scheduling or installing services. (I bet those guys went 'Doh' when they learnt about the schedule workaround!)
From the fine Washington Post article you referenced:
We all know how well that turned out for XP and 2003 and how "security as job 1" cleaned up the botnets and eliminated spam. No? Well, at least they got input to their random number generator and everyone knows that a backdoored system is the one to use for great security. Go Team America!
No calls now, I'm
To me, this looks like a perfect example of UAC doing exactly what it was designed to do; forcing developers to write software that will run for non-administrative users. Heck, we read about it here just a few weeks ago:
http://tech.slashdot.org/article.pl?sid=08/04/12/006242
As far as I know Microsoft haven't said anything about this, but it wouldn't be surprising to see a version of Windows in a few years that by default creates a non-administrative account during setup and encourages the home user to use that one for day-to-day activities. UAC is just a first step towards making that feasible.
College-Pages.com - Online Colleges, Degrees, and Programs
If they wanted to set up a shortcut in the Startup folder to an executable that needed to run with Administrative privileges, they could use IShellLinkDataList::SetFlags to modify the shortcut in their installer package.
The purpose of UAC (or so I've heard) is so that applications won't embed themselves too deeply inside the OS. Basically, most of the actions that cause UAC to pop-up really just shouldn't be done in the first place. Of course there are exceptions, like just installing applications. But Microsoft's goal was to force developers to quit embedding apps into Windows by making it really annoying for users to use applications that do. It's a really douchy way of accomplishing that goals, that's for sure, but by coding around it you're just part of the problem.
You split your admin-only program to an admin-service and unprivileged client. Bravo guys. You just reinvented the wheel.
Now you want to work on preventing *anyone* from calling your admin service and messing with whatever it can do. And no, don't invent custom noone-can-figure-it-out protocols, it does not work that way.
Between Vista and the XBox fiasco I'm thinking their stock may have further to crash.
- mildly
. In xp and 2000 you still have to watch your temp files an make sure they don't grow to an extension of a full blown worm. To get around that, simply download Windows defender which renders any temp file useless as long as IE7 is not open, or any other http PNG running program that exchanges xml docs are not encrypted.Meaning, If another program is not configured to run with its own syncronized xml doc exchange or better known as 'encryption'. Then Microsoft believes thats the composer's problem of who made that program. Such as yahoo messenger, VEOH, Winamp, ect.. Programs that uses Microsoft Internet Explorer's Temp file resources. Microsoft believes they are not paid to make anyone elses programs 100% safer then to certify they're own(Microsoft) programs. Even when Microsoft made they're open source active x resources so easily spoofed. They still would make you pay in order to get customer service. of ANY type.
But you know it is possibly made that way to allow the common user or program vender to need to call Microsoft an pay a nice sum of money to fix they're computer problem(s). Which is all beyond the point.
Which as you see No new IE 8, no new framework patches.. yet. Microsoft seems to be letting all the other browsers(Fire Fox, Opera, Netscape) update first before they toss the new Internet Explorer 8 into the field. Which by then all exploits in frame work Certificate encryptions should be 100% safe once more.
Have you seen the new Silverlight? Microsoft's adobe flash look a mock-up. Seems Microsoft isn't only trying to buy Yahoo! but plow over adobe's internet content handler as well with they're Silverlight.
The way Bill Gates is handling all the internet problems seems pretty devious. As you may have noticed that the Vista is alot more critically dynamic and secure. Sort of like Linux secure, Picky over drivers. Some programs wont even launch if you do not adjust some things. Bill Gates probably never anticipated for the internet to be Windows failing point, but The way Vista runs.. Seems like Bill Gates is not going to let the Internet stop Windows, but Windows conquering the net.. VERYY DEVIOUS..
Bill Gates have seen the certificates, and the js exploits. As you an I can see in the certificate been the 2 small fraudulent certificates. Out of the billion that have been most likely set off threw the net. Bill Gates has an ace up his sleeve, and it looks like one of his moves is taking out adobe along with what ever else he finds wrong.
Other then the old IE7 Vista is a monster that is yet to be completed in its superirority over the net. Linux is fishing for something to top it, an have not yet.. Have you gotten your first service pack yet?? I know i haven't did i mention the silver light???
On the contrary, on OS X most user-installed apps install by drag-and-drop and are owned by the user who installed them not root. Whether that's a good thing or not might be a moot point, but it's so.
If you'd ever used the OS, you'd have known that, so you have no grounds for calling someone else "delusional". You are quite simply wrong.
Here is the documentation:
http://developer.apple.com/tools/installerpolicy.html
UAC... sounds familiar... It is from that Doom game, right?
What exactly do you mean by a false positive anyway? UAC prompts for exactly the same reasons as something like sudo prompts.
Any fool can create a DAEMON or service running under the root account, and then allow user accounts to utilise that service to bypass UAC.
... so how is this ANY different from a linux system where you'll need to do su and supply the root password ???
... because it's easier to show a popup window that the wife and kids can understand rather than telling them they'll need to go into a shell, type su and the root password, before they can even use it.
... this is exactly the behaviour I expect out of UAC, and it's exactly what I get.
... but to me UAC IS working correctly ... certain groups just choose to perceive it as painful for their own agendas.
This is no different from Linux and I suppose Mac also.
The "trick" is to get the DAEMON running as root WITHOUT having to deal with UAC, root permissions or whatever.
This is not "news", just typical anti-microsoft FUD.
I'm sorry, I know UAC is a pain, but in general, (MS bias aside), I've found it does exactly what it says on the tin. I installed Vista on my PC at home, have a root account for Admin purposes, and then set up User accounts for the wife and kids.
On their accounts, every action that is potentially dangerous requires my Admin account password
I'll tell you
"Double click on icon, UAC popup, call Dad to approve it"
Note I'm not particularly a MS fanboy, and use Linux webservers all day in a LAMP environment for my job as web programmer
and having all your libraries in the windows system directory, or installed programs in "program files" and so on and so forth.
If I install a game, it shouldn't require ANY "root" prives because it should only be writing to places I have access to and these should not be common directories. If I *do* install as root, the application can become universally available, but it shouldn't be necessary to do so.
Loki installer does this and has for years. Why can't Windows?
Am I the only one who saw 'UAC' and thought 'Doom' ?
What a depressingly stupid machine.
All these comments and not a single mention of how we defeated the UAC waaaaay back in Doom I!
I'm not sure about some other people's comments, but as a Windows developer, I have come to exactly the same conclusion as this article. Especially this line: "Windows Vista's improved security model is nothing more than a series of obstacles that in reality only make it more difficult for honest ISVs to publish working code and not actually providing any true protection from malware authors."
After I'm-not-sure-how-many shipped Windows applications, I have to agree.
Still, I'm not a security expert, like some of the people here.
burrocrisy
and that would be what? Ruling by jackasses? Never has a slashdot misspelling been more apropos
His workaround uber hack that completely makes UAC worthless requires an installer that has to be run under an admin level account.
Nothing is broken or worked around here. He just figured out how to make a userland app talk to a server account (that was installed as administrator) without causing a UAC popup.
Big deal? Not really.
Prevent linux based DDOS's!
http://linux.denialofservice.org/
Yes, please code around it, and then we'll have a good laugh when your programs are broken on future versions.
Didn't you idiots learn your lesson about not following design guidelines? Apparently not.
Actually, the UNIX security model is quite finely grained when used as designed.
The problem is that it was designed with these assumptions:
1. Access to resources is controlled by access to files in the file system.
2. Access to resources is associated with user ID and group membership.
3. Privilege elevation is always managed by gateway applications running with appropriate user and group ID.
That is, if you want to limit access to a serial port to people who need to dial out, you put the serial port in the group "dialer" and the dialout software setgid "dialer", and let it limit access appropriately.
Some programs did the right thing, some didn't, but it was Berkeley Sockets that smashed it good an proper. The right thing to do would have been something like this: make "bind()" take an open file as an argument, and make the special file "/dev/sockets/25" owned by group "mail", then run the mail listener setgid "mail". It would open "/dev/sockets/25", pass that to bind, and have an open listener on the SMTP port without having to run as root.
Unfortunately, instead of that, you had to be root to open sockets in the reserved range. And the floodgates were open.
Funny, just got in from a weekend of self imposed computer exile, read here on slash, what I discovered last week. In my case, my installer, in addition to installing the core application, installed a service. Found I had a need to respond to some normal, globally broadcase win messages, and "do" things in responce to them that normally required admin privilege. What I found/discovered, is that my service could hang around waiting for an interactive user to log-in, get copy the security tokens for any number of processes that ALWAYS run when a user logs in, and then and again from the service, launch my choice of executable code with the same credentials as the user (and in their desktop), but with all the privilege of trusted system service. As all it takes is the one UAC prompt at the time of installation of the service (which users click almost like Pavlov's dog responded to a bell), I do see this as a glaring security hole that I hope (as a developer), is never "fixed". I have finally found a way to be able to deploy on Vista ALMOST as flexibly as I can deploy on XP. So in the end, I strongly agree all microsoft did with UAC is to screw honest 3rd party developers, and find a way to blame users for all of Microsoft's security issues.
Nothing evolves faster than the word of god in the minds of men who think themselves divinely inspired.