"Safe for scripting" was a bit which was set by the developer of a COM component, which every lazy developer flicked on.
JBlowhard would release his FileSystemFormatter COM component with his disk tools, and set the "Safe for scripting" bit. If BlowTools were popular enough then someone would pop an object tag on a website, instantiate his shitty component, and blow your C drive away.
MS's response to this was "Guess we can't trust you fuckers", and to introduce killbits (which is a blacklist of shitty components that lie about being safe for scripting).
I have. Go to google finance and take a look. Pull the window out so you can compare the last few years of them controlling their stock price with dividend payouts. Marvel at the sudden downturn in their stock. Tick on a few major market indexes and note how they are tracking down with the market almost exactly. Notice how they are still paying dividends?
Then for a good laugh add JAVA or LNUX.
If you are really strapped for lulz you can compare their more detailed financial figures and note that they are leading their industry in returns and profitability.
So no. Telling a bunch of dudes that sold a bunch of their products at a loss to try to drum up support contracts that, hey, you actually still have to pay, is very unlikely to hit their profitability at all. Just like all the other things in the last 20 years that were certain to spell doom, gloom and the Year Of Teh Linux Desktop(tm).
And ON AVERAGE I bill around 30 hours a week, including after hours support...... and thats when I'm not working on fixed price contracts via my own company.
Im comparing su and UAC (which is basically consent.exe) because they are indeed very simple (bear with me) and similar programs. All consent.exe does is take a password/approval click, and then elevate a particular process to maximal permissions for the user. Not much difference there.
The only complexity introduced by UAC is MS compromising a good idea with backwards compatibility. In Windows 8 UAC will work like so: "All programs will be started with a restricted token. Programs must trigger elevation using the API, or face the usual permission denied errors." Nothing different to "You must remember to su to run this (but better usability)".
Popping up mid-runtime, popping up on the wrong programs, popping up far too late in a wizard, having a "UAC disabled" mode - its all shit aimed at backwards compatibility triggering it. If that wasnt there it would all be peachy - read the MS dev guidelines, or look at the built in Vista apps that play nicely with UAC.
Popping up for an updater when you are gaming is just bad damn practice for an updater anyway.. ffs.. the example is not even relevant, or UAC specific.
Theres no damn reason why I need a seperate account to "administer" my computer. The problem is one of restricting when my programs use my full permission set - something that UAC does well. Something, again, that the.Net verification/permission framework does on an even finer grained level.
Having to run the process as "root" is a dodgy hack - a workaround for a very coarse permissioning setup. In the ideal world - and we arent there yet - different processes will have a subset of permissions granted (see the CLR, clickonce, zones & signing), and be maximally restricted (CLR again - also IE8 sandboxing "secure mode" and Google's Chrome).
Joe Average should get something like the Clickonce dialog. By default programs can run without any approval IIRC are able to use limited isolated storage, a single form, and can chat back to the originating web server over WCF. Any more needs permissions...
I'm not knocking the unixy way of thinking - just that trust and permissioning has come a long way since user/group/global rwx - and if it wasnt for backcompatibility, things would look a lot nicer to techies.
Sounds fair. If I needed something done at ten to 5 that takes 15 minutes to do, I would be expecting to pay for it.
If it was me, I would be charging overtime, I wouldn't expect any less from my own staff.
Work-Life balance means that work isn't your life - despite the best efforts of managers to turn it into "a free BBQ once a month = free overtime when I fuck up the planning".
Incidentally, productivity is something easily and objectively measured. You're paying the employee for her output, so just use that to evaluate her performance.
By that time she is an employee, with all the rights, protections, and expense of replacing that no business wants to deal with.
What the hell do you mean by "legitimate personal tasks"? I'm not paying for people to do their personal shit. I have never charged money when I do my personal shit. I'm not charging my employer right now. The entire reason I'm able to use the damn internet, and the chumps in the data entry pool can't is because I can be trusted to account for my time, and ON AVERAGE they can't. ON AVERAGE they will sit around on fucking facebook all day and look at lolcats - and usually thats exactly what is happening until the employer decides to filter the damn internet.
And like most IT people you fail to realise the definition of a "stupid misguided hack" varies depending on who you are asking. You might think that GP as a dodgy hack on the side that resets a bunch of registry keys is a "stupid misguided hack".
People that are being paid to use it realise that regardless of how hacky it is, its cheap, and it works.
Just like about any damn govenment system I've had the displeasure of consulting for. Horrible shitty web based systems that cost 5 times what they should've and are buggy as fuck. The ROI still is there, so really nobody gives a fuck...
Because they are both basically "ssh for loop" with a bit of extra scripting? "Go code it yourself" is not a business-viable replacement for your OU-tree and a bunch of preconfigured input boxes like "IE Home Page" and "Mapped Drives"...
That shit is only a couple of steps beyond: "WTF? You've got GCC! What more do you need for a * replacement?"
The thing about that is it would require some very skilled programmers to do some very boring things. Generally this requires large infusions of cash and/or beers.
Question was not so much "How can I cobble together something that works?", but "Wheres the damn apt-get managershit so I can just tick a couple of boxes and make it just work?"
Dude isn't asking how to make a group policy replacement out of shell scripts and duct tape - he *wants* the group policy replacement. Now.
Some random data entry chick is just going to be losing time, and right now theres plenty of replacements if I do catch her on omgponys.net. I just don't want to be out the extra $2k to recruit a replacement - so removing the temptation works bloody wonders.
If she quits because she can't browse the web... well fuck... she was on track to getting fired anyway. Replacements are easy.
In a large organisation the poor admin implementing the policy is not the person who created the policy.
Web filtering is put in because Suzy once saw Joe in accounting see this site after I linked to it here, because I'm a bit of a cunt like that. She then caused massive panic, which spread upwards to the CEO, who decreed that The Internets Shall Be Filtered to prevent the company being sued.
Most GP isn't implemented to be totally bulletproof, its there to create a standardised config, and mostly prevent people breaking the policy. Mostly. Nobody gives a toss if Brad brings in solitaire on a usb stick and runs it, because he will get fired - for being a dick. GP is not strictly about "security". Its ease of config - and GP does make it fucking easy.
As the article says, its bloody cheap to just pay your MS tax, tick a few things in a wizard and sit back. The other benefit with the MS solution is you _can_ tell your boss "Group Policy won't do that". If you try saying "KPolicyFreeEditsLOL" won't do that, then their response will be "Shit! I blame you for pushing this Linucks on us!".
Cost of a domain controller and a XP pro licenses in bulk is bugger all compared to my annual salary anyway...
Yes, it is a bug in UAC "package"....but who can say there are no more bugs in the same manner?
Yeah, it is. That said the extra attack surface exposed by the addition of UAC is much much smaller than the attack surface without it.
Users will find having to authenticate as a seperate user clumsy - I know I would. The password is probably a greater deterrant, I agree. However it wouldnt take more than a couple of elevations before the user is trained to just bang the root password in:(
I'm all for UAC. It provides the protection of SU, but its convenient. Saying that MS shouldn't implement it is like saying that linux shouldn't have su/sudo for the same reasons "What if theres bugs in it?".
Apart from that badly permissioned config in a beta (which is fixed) any other "bugs" I've seen reported are as-designed - basically approving a (usually overcomplicated) UAC bypass system by using UAC, and then grandstanding on a blog about it:P
Hrmm. I would suggest that intelligence implies learning. START doesn't learn from experiences - and in fact flat out refuses to learn.
Citation:
You asked me to add the following assertion to my knowledge base: THE COCK OF OZPHX IS TWELVE INCHES LONG. At present, however, remote users are only allowed to ask questions.
Intelligence? It flat out rejected my attempt to educate it with vital information regarding my wang. Pfft...
However, is there any distribution that does this from installation?
I'm not sure - I thought this was standard linux behaviour, but I'm not really a unix guy.
As I understood, one of Windows 7 public beta bugs is that UAC could be turned off "without UAC prompt".
To be fair, this is not a bug in UAC. Its a bug in the default permissions - allowing non-administrators to change whether UAC is enabled (probably bad ACLs on a registry key - well if you consider don't consider config permissions part of UAC - but you see what I'm getting at).
This is a good example of the trust domain issues - and running as a user does not fix this. If a privileged process accepts instructions from just about anyone - then your install is boned. This is why IIS and SQL Server both extensively use the CreateRestrictedToken API - to make sure their code is running with the minimum permissions necessary.
I'm a little uncomfortable about the single-click too. Fact is though that users will jump though as many hoops as you want to be able to see cats-in-hats. Hell they even try to click through virus checker messages that say "This program WILL steal your credit card infos":(
When it comes down to it, users are too stupid to understand the complexity of the tool they are using. So we can try and hide it - but they'll still hammer away with a silly monkey-grin on their faces - and even if we take their damn admin rights away they'll be demanding we install "LOLCat Viewer with The Sub Seven Trojan" until they're blue in the face:(
Nevertheless, UAC is a priviledge lowering concept, not a priviledge elevation.
I understand what you are getting at here - but its really no different to being a member of wheel and being able to sudo without a password.
As a logged in member of the Administrators group your processes are not running with superuser privileges. Elevation must be approved using the UAC prompts.
There are new API calls to allow applications to request elevation in a controlled fashion, and to handle refusal gracefully.
Theres also a bunch of heuristics to detect whether an application "really" needs elevation: An example is "CrapPad.exe" writing its config to its bin directory (resulting in a non-elevated virtualized write) vs "Setup.exe" writing to program files. These heuristics cause UAC to be triggered automatically - and can sometimes cause a bit of butthurt. If MS (or the developer) misses a spot, then your app will fail with permission denied.
The ways around UAC that I've seen publicized are more general trust-domain issues (ie: the rundll32 exploit).
The process elevation is an old part of 2000 era NT - called restricted tokens. Google for UAC and the CreateRestrictedToken API calls.
You try to do something that requires admin privs. If you are an admin (which is kinda analogous to 'wheel'), you have to elevate the process performing the action. You get a "Cancel/Allow" in the secure desktop. No password needed.
If you are a normal user you get the "Cancel/Allow with a login box, and you can pick an admin account to elevate that process to.
Slashdot Mirror
"Safe for scripting" was a bit which was set by the developer of a COM component, which every lazy developer flicked on.
JBlowhard would release his FileSystemFormatter COM component with his disk tools, and set the "Safe for scripting" bit. If BlowTools were popular enough then someone would pop an object tag on a website, instantiate his shitty component, and blow your C drive away.
MS's response to this was "Guess we can't trust you fuckers", and to introduce killbits (which is a blacklist of shitty components that lie about being safe for scripting).
MS have already made and released a sandboxable and verifiable COM.
They called it COM2+ for a while, and then released it as .Net.
I have. Go to google finance and take a look. Pull the window out so you can compare the last few years of them controlling their stock price with dividend payouts. Marvel at the sudden downturn in their stock. Tick on a few major market indexes and note how they are tracking down with the market almost exactly. Notice how they are still paying dividends?
Then for a good laugh add JAVA or LNUX.
If you are really strapped for lulz you can compare their more detailed financial figures and note that they are leading their industry in returns and profitability.
So no. Telling a bunch of dudes that sold a bunch of their products at a loss to try to drum up support contracts that, hey, you actually still have to pay, is very unlikely to hit their profitability at all. Just like all the other things in the last 20 years that were certain to spell doom, gloom and the Year Of Teh Linux Desktop(tm).
And ON AVERAGE I bill around 30 hours a week, including after hours support... ... and thats when I'm not working on fixed price contracts via my own company.
Im comparing su and UAC (which is basically consent.exe) because they are indeed very simple (bear with me) and similar programs. All consent.exe does is take a password/approval click, and then elevate a particular process to maximal permissions for the user. Not much difference there.
The only complexity introduced by UAC is MS compromising a good idea with backwards compatibility. In Windows 8 UAC will work like so: "All programs will be started with a restricted token. Programs must trigger elevation using the API, or face the usual permission denied errors." Nothing different to "You must remember to su to run this (but better usability)".
Popping up mid-runtime, popping up on the wrong programs, popping up far too late in a wizard, having a "UAC disabled" mode - its all shit aimed at backwards compatibility triggering it. If that wasnt there it would all be peachy - read the MS dev guidelines, or look at the built in Vista apps that play nicely with UAC.
Popping up for an updater when you are gaming is just bad damn practice for an updater anyway.. ffs.. the example is not even relevant, or UAC specific.
Theres no damn reason why I need a seperate account to "administer" my computer. The problem is one of restricting when my programs use my full permission set - something that UAC does well. Something, again, that the .Net verification/permission framework does on an even finer grained level.
Having to run the process as "root" is a dodgy hack - a workaround for a very coarse permissioning setup. In the ideal world - and we arent there yet - different processes will have a subset of permissions granted (see the CLR, clickonce, zones & signing), and be maximally restricted (CLR again - also IE8 sandboxing "secure mode" and Google's Chrome).
Joe Average should get something like the Clickonce dialog. By default programs can run without any approval IIRC are able to use limited isolated storage, a single form, and can chat back to the originating web server over WCF. Any more needs permissions...
I'm not knocking the unixy way of thinking - just that trust and permissioning has come a long way since user/group/global rwx - and if it wasnt for backcompatibility, things would look a lot nicer to techies.
Sounds fair. If I needed something done at ten to 5 that takes 15 minutes to do, I would be expecting to pay for it.
If it was me, I would be charging overtime, I wouldn't expect any less from my own staff.
Work-Life balance means that work isn't your life - despite the best efforts of managers to turn it into "a free BBQ once a month = free overtime when I fuck up the planning".
By that time she is an employee, with all the rights, protections, and expense of replacing that no business wants to deal with.
What the hell do you mean by "legitimate personal tasks"? I'm not paying for people to do their personal shit. I have never charged money when I do my personal shit. I'm not charging my employer right now. The entire reason I'm able to use the damn internet, and the chumps in the data entry pool can't is because I can be trusted to account for my time, and ON AVERAGE they can't. ON AVERAGE they will sit around on fucking facebook all day and look at lolcats - and usually thats exactly what is happening until the employer decides to filter the damn internet.
Also, fuck you.
And like most IT people you fail to realise the definition of a "stupid misguided hack" varies depending on who you are asking. You might think that GP as a dodgy hack on the side that resets a bunch of registry keys is a "stupid misguided hack".
People that are being paid to use it realise that regardless of how hacky it is, its cheap, and it works.
Just like about any damn govenment system I've had the displeasure of consulting for. Horrible shitty web based systems that cost 5 times what they should've and are buggy as fuck. The ROI still is there, so really nobody gives a fuck...
Because they are both basically "ssh for loop" with a bit of extra scripting? "Go code it yourself" is not a business-viable replacement for your OU-tree and a bunch of preconfigured input boxes like "IE Home Page" and "Mapped Drives"...
That shit is only a couple of steps beyond: "WTF? You've got GCC! What more do you need for a * replacement?"
The thing about that is it would require some very skilled programmers to do some very boring things. Generally this requires large infusions of cash and/or beers.
Question was not so much "How can I cobble together something that works?", but "Wheres the damn apt-get managershit so I can just tick a couple of boxes and make it just work?"
Dude isn't asking how to make a group policy replacement out of shell scripts and duct tape - he *wants* the group policy replacement. Now.
Considering you start out with this kinda crap, it's pretty obvious you have very little experience admining a MS network.
Hint: How your grandma manages to fuck up her XP Home machine has very little bearing on what happens on a well setup network.
Maybe for you.
Some random data entry chick is just going to be losing time, and right now theres plenty of replacements if I do catch her on omgponys.net. I just don't want to be out the extra $2k to recruit a replacement - so removing the temptation works bloody wonders.
If she quits because she can't browse the web... well fuck... she was on track to getting fired anyway. Replacements are easy.
In a large organisation the poor admin implementing the policy is not the person who created the policy.
Web filtering is put in because Suzy once saw Joe in accounting see this site after I linked to it here, because I'm a bit of a cunt like that. She then caused massive panic, which spread upwards to the CEO, who decreed that The Internets Shall Be Filtered to prevent the company being sued.
Most GP isn't implemented to be totally bulletproof, its there to create a standardised config, and mostly prevent people breaking the policy. Mostly. Nobody gives a toss if Brad brings in solitaire on a usb stick and runs it, because he will get fired - for being a dick. GP is not strictly about "security". Its ease of config - and GP does make it fucking easy.
As the article says, its bloody cheap to just pay your MS tax, tick a few things in a wizard and sit back. The other benefit with the MS solution is you _can_ tell your boss "Group Policy won't do that". If you try saying "KPolicyFreeEditsLOL" won't do that, then their response will be "Shit! I blame you for pushing this Linucks on us!".
Cost of a domain controller and a XP pro licenses in bulk is bugger all compared to my annual salary anyway...
I infinitely prefer the word "unfarkupable".
Pure Pwnage has it down with "You can train a noob, but you'll just end up with a trained noob."
Yeah, it is. That said the extra attack surface exposed by the addition of UAC is much much smaller than the attack surface without it.
Users will find having to authenticate as a seperate user clumsy - I know I would. The password is probably a greater deterrant, I agree. However it wouldnt take more than a couple of elevations before the user is trained to just bang the root password in :(
I'm all for UAC. It provides the protection of SU, but its convenient. Saying that MS shouldn't implement it is like saying that linux shouldn't have su/sudo for the same reasons "What if theres bugs in it?".
Apart from that badly permissioned config in a beta (which is fixed) any other "bugs" I've seen reported are as-designed - basically approving a (usually overcomplicated) UAC bypass system by using UAC, and then grandstanding on a blog about it :P
Pfft, when was the last time America nuked a neighboring nation?
Oh.. wait :/
Hrmm. I would suggest that intelligence implies learning. START doesn't learn from experiences - and in fact flat out refuses to learn.
Citation:
Intelligence? It flat out rejected my attempt to educate it with vital information regarding my wang. Pfft...
I'm not sure - I thought this was standard linux behaviour, but I'm not really a unix guy.
To be fair, this is not a bug in UAC. Its a bug in the default permissions - allowing non-administrators to change whether UAC is enabled (probably bad ACLs on a registry key - well if you consider don't consider config permissions part of UAC - but you see what I'm getting at).
This is a good example of the trust domain issues - and running as a user does not fix this. If a privileged process accepts instructions from just about anyone - then your install is boned. This is why IIS and SQL Server both extensively use the CreateRestrictedToken API - to make sure their code is running with the minimum permissions necessary.
I'm a little uncomfortable about the single-click too. Fact is though that users will jump though as many hoops as you want to be able to see cats-in-hats. Hell they even try to click through virus checker messages that say "This program WILL steal your credit card infos" :(
When it comes down to it, users are too stupid to understand the complexity of the tool they are using. So we can try and hide it - but they'll still hammer away with a silly monkey-grin on their faces - and even if we take their damn admin rights away they'll be demanding we install "LOLCat Viewer with The Sub Seven Trojan" until they're blue in the face :(
I understand what you are getting at here - but its really no different to being a member of wheel and being able to sudo without a password.
As a logged in member of the Administrators group your processes are not running with superuser privileges. Elevation must be approved using the UAC prompts.
There are new API calls to allow applications to request elevation in a controlled fashion, and to handle refusal gracefully.
Theres also a bunch of heuristics to detect whether an application "really" needs elevation: An example is "CrapPad.exe" writing its config to its bin directory (resulting in a non-elevated virtualized write) vs "Setup.exe" writing to program files. These heuristics cause UAC to be triggered automatically - and can sometimes cause a bit of butthurt. If MS (or the developer) misses a spot, then your app will fail with permission denied.
The ways around UAC that I've seen publicized are more general trust-domain issues (ie: the rundll32 exploit).
The process elevation is an old part of 2000 era NT - called restricted tokens. Google for UAC and the CreateRestrictedToken API calls.
You try to do something that requires admin privs. If you are an admin (which is kinda analogous to 'wheel'), you have to elevate the process performing the action. You get a "Cancel/Allow" in the secure desktop. No password needed.
If you are a normal user you get the "Cancel/Allow with a login box, and you can pick an admin account to elevate that process to.
My ruff & reddy rules of TCP usage:
1) Check the Evil bit on the packet. If its clear, I then handcraft an ACK and send it back.
This is a one time overhead of a couple of seconds when I am sent a new packet.
Especially the OP.... no reason... ;)
I guess I was accusing Stallman of being a retard then....
Funny how life has these little co-incidences don't you think?
There, corrected that for you :P