Truecrypt can only encrypt a non-system partition, or create a virtual partition on a file.
Vista's bitlocker is whole-disk, as in you cant have access to windows until you've started the pre-loader and entered your password or smart-card.
So the pagefile, temporary files, windows system files, etc are all always encrypted.
One of the only other significant competitors for whole-disk encryption is the commercial PGP product.
2. Key-Escrow (or equivalent through multiple decrypting accounts)
So what do you do when a person leaves their job and doesnt tell you the password? You'll need to be able to get into it and decrypt it, or better yet, give someone else's account access to the volume.
True crypt has a real hacky way to do the latter, which you can see in their FAQ.
In your car between clients, want to do some email and catch up.
Sitting outside a business after doing some work.
Sitting in another business that doesnt have wifi or other network you can use.
Sitting in an airport that doesnt have wifi (too damn many even today), or when you dont want to pay $10 for 20 minutes of email.
Sitting in restaurant or coffee shop that doesnt have free wifi (or that you dont want to pay for).
Now I know that not everyone lives the way I do, and so online/offline performance isnt critical to everyone. But just about anyone who primarily uses a laptop because they need one, there's always some place or another where you've got downtime, but no network.
So yes, its not common for home users, but its very common for IT professionals, and managers/PMs/Business Analysts in just about any business.
I can go into any Internet cafe in the world and load up my webmail page (my own web and mail servers), as long as they allow https. And the first time you do that, you've just given up your email user/pass to the 18 script kiddies and 3 black-hat pros who have installed key-loggers on that machine. A few hours later, your email creds are being sold on forums, or being used to spam.
Webmail using anyone's machine but your own is not useful, as there is no security.
How can you absolutely guarantee that every single not-owned-by-you computer is not compromised and infested with key-loggers, or that the owner could profit from some corporate espionage by stealing your email login?
People say that Outlook is dangerous due to security issues (which havent really been a problem since Outlook 2000), but they'll go to some random kiosk managed by someone they dont know, assuming its even managed at all, and blindly share their user/pass with anyone who's installed a key-logger on the machine?
The problem is that if you want any sort of even mediocre security whatsoever, you have to carry around your own laptop with you.
Otherwise, you're having to trust that every single computer you use to use gmail is managed well enough by its owner that its absolutely guaranteed not to be compromised and have a key-logger (nearly all 'kiosk' types of computers are thus compromised), and that the owner itself would never consider stealing your gmail login.
In other words, its utterly useless unless you carry around your own laptop with you, and at that point, why not just use Outlook.
Because if my shop doesnt already use MySQL, then its adding an entire new DBMS just to support one app. That's expensive.
Most shops settle on one 'utility' db for stuff like this so that they can amortize their maintenance costs across everything they use it for. Think of all the highly specialized functions surrounding a DB server that you've got to do: backup, patch, monitor, upgrade periodically, and generally just maintain it (ie, make sure its tuned right for memory, not running out of disk, has the right firewall ports opened, etc etc).
So if I've already got PostgreSQL or MSSQL or whatever, having to add an entire DBMS just to host one app whose developers couldnt be bothered to use a DAL (Data Abstraction Layer) is irritating, and is often a dealbreaker. It makes using that app much more expensive (in terms of ancillary maintenance costs) than it would have to be if it was just backed by ODBC/JDBC/Pear/whatever, and you could plugin whatever DB you wanted.
The big problem I see with this "mandated configuration" approach, is the insistence on a common desktop configuration, and its enforcement through Active Directory. This forces an integrator to turn on services and open ports on a desktop that would not ordinarily need to be opened - purely to amuse Microsoft's centralized management scheme. Neither of us have seen the new fed.gov security, but I think you're misunderstanding the situation. It's not a matter of workgroup vs. domain, but of 'poorly-locked-down-domain-workstation' and 'highly-locked-down-domain-workstation'.
No department could or would want to run as a workgroup... you lose all the bennies of running the microsoft stack that way.
Additional services like Distributed Transaction Coordinator, Remote Registry Service, Server Service (which exposes the IPC$ share - you can't shut this off anymore), Microsoft Installer, Task Scheduler (which has a long and sordid history of unpatched vulnerabilities), Automatic Updates, Background Intelligent Transfer Service, Computer Browser service, DCOM Server Process Launcher, Error Reporting Service - etc. the list goes on and on. You can shut off most of this crap on a Workgroup machine. A Domain member needs to have a lot of these turned on - and that exposes a lot more surface area to attack. The expertise to determine which services support which functionality; what you can turn off and still get done - is not cheap or easy. Most of these services, you can't google on and get a meaningful answer, nor is Microsoft's documentation always clear. It's not that hard, and would take a competent sysadmin about a day to figure it all out.
And thats half the point of a common security config, you've reduced the surface area to a minimum amount.
I havent seen the fed.gov specifics yet... but I'd bet its basically the same thing that nsa suggests for configuring your boxes.
Things like:
- minimum password lengths - minimum password complexity - password rotation - password strength auditing - running all users as non-admin - do not store lm hash - sign & encrypt all cifs & ldap communications - do not allow anonymous access to anything (shares, sam, etc) - X services set to disabled - host-based firewall running - anti-virus running - run services as network service or other non-prived accounts - etc.
So how does having all the computers configured thusly make them all more vulnerable, just because they're the same?
In every case this makes the system more secure. About the only possible monoculture issue that could come up is the a/v and firewall. If they're all by the same company and they all suffer from a vulnerability then there's a weakness. But this is probably already the case anyway, as the big fed departments all will sign big contracts with an a/v vendor for cheaper prices.
Some IT folks in fed.gov have come up with a security policy (ie, group policies, registry tweaks, acl changes, user-rights changes, etc). They are saying that they will be running all vista machines with that exact security policy enforced.
They are then saying that to be able to big on software contracts, the ISV must certify that their software will run on Vista configured with this policy.
Microsoft is not involved in any way.
It's not Microsoft creating the security policy. It's not Microsoft creating a new vista sku. It's not Microsoft creating a certification program to sign & cert tested software. It's NONE of these things.
So to be crystal clear here... Microsoft is not giving anyone permission for anything.
If you could be bothered to read TFA you'd see that.
"Long story made short - larger vehicles will always consume more energy then smaller vehicles. Sorry Hummer owners, but it's true."
While thats technically true its a bit trivial. Many, many people require a larger vehicle for any number of reasons. Ever try to haul camping gear and a trailer full of quads to the sand-dunes in a prius? Ever try to sleep in the back of your prius in the forest (not sure if its possible for most, but it would be way too small for me)?
"Don't forget the fact that larger engines consume more gas. They are designed to produce a larger peak power and as such, require stronger, heavier parts. Moving heavier parts requires more energy thereby increasing fuel usage."
Not really. A larger engine is typically used to provide more torque, which is required for hauling, not for more peak power. It's often more efficient (economically) to use a smaller, very high-strung (ie, turbos, etc) engine to producer higher peak power. Usually thats done by designing the engine so that it can run to a higher peak rpm. In that scenario (high-rpm) big engines do particularly poorly, as there's that much more steel to slop back and forth.
But increasing displacement is really the only way to increase torque (in general), so therefore you have larger engines in trucks, SUVs, etc where torque is more important than peak horsepower.
Okay, this requires a response. Do you really believe this nonsense on the page you've linked?
Okay, so lets turn on our logic circuit (ie, brain), and think about this thoroughly, and not just regurgitate what someone tells us.
MPG (Miles Per Gallon) is only one measure of impact to the environment and overall 'cost' of cars.
For a MPG rating to be meaningful between two vehicles, they have to share some common traits:
1. Similar weight. The heavier the car gets, the lower your MPG gets. But many vehicles (ie, trucks) require some of that weight for beds and towing.
Your typical family car weights ~3000 pounds nowadays, compared to the model T which weighed 1200 pounds for the open roadster, and a bit more for the enclosed car.
2. Safety. Massive federal regs in the US have required massive changes to cars that increase safety. We're all very happy about this. However, this tends to make a car much heavier (see #1 above).
Do you want to bet what is going to happen if you have a head-on collision with a modern family sedan and a Model-T? Which car would you want to be in?
3. Power. The market (ie, buyers/people) want more power in their cars, and they're willing to trade fuel-economy for it. Plus it take alot more power to push around a 3000 lb car than it does a 1200 lb car.
For comparison, the Model-T produced ~20hp (somewhere between 1/5 and 1/10 of the family sedan of today), with a 2.9L 4-cylinder, 4-stroke engine.
4. Pollution. Anti-pollution technologies (lean-burning, catalytic converters, etc) all reduce power and add weight.
How much noxious chemicals do you think the Model-T was pumping out of its tailpipe and oil-dripping from the engine? Compare that to the modern ULEV or better car, where you can almost use the exhaust for breathing-air its so clean.
So even if they really dont get any better fuel economy out of the 'typical' car now than then, you're getting 5-10x the power, and 2-3 times the top speed at twice the weight and an order of magnitude more safety. All that with practically zero emissions, and massive comfort, air-conditioning, zoned-temperature-control, and a dvd-player in the back-seat.
So miles-per-gallon is only one dimension that you care about, there's also miles per death, average-miles-per-hour (more power equals go faster equals less time spent driving equals more time spent living life), emissions-per-mile, and mile-pounds per gallon.
So to tie us back to the grandparent, yes, there really has been massive amounts of progress. Just because it isnt in a naive analysis of miles-per-gallon doesnt mean it isnt meaningul, it just means that its not what the market and governments care about. Other factors are much more meaningful.
why not throw in an e-mail server? If you make it simple (ie: SquirrelMail seems to be a popular campus e-mail hosting app, probably cause of it's cost and simplicity), I wouldn't think size would be an issue, as long as you set the proper quotas per e-mail/user.
This only works for the very smallest of the small colleges & universities.
My alumn, for example (which is not a particularly huge school), runs at 50,000-60,000 email accounts (students, staff, affiliates, etc), at 500MB each.
So thats ~60TB of data. And given the need for uptime and reliability, this means a very expensive highly redundant SAN, plus load-balanced (ie, clustered) front-end servers. Plus backup.
Figure at least a few hundred thousand dollars per year, in (amortized & ongoing) hardware costs and costs for staff time for updates, maintenance, support, etc. And thats with a full open source email stack.
So to answer your question, running email for a mid or large sized university is very expensive. Even more so given how fundamental email becomes to most organization... try taking down the email server for a university and see how much work gets done.
But anytime you are spending that kind of cash on non-core (ie, not education or directly supporting education) service, you're obligated to at least consider alternatives.
Mind you, I dont think that outsourcing email is a good idea for Universities. And many universities cannot do this, as staff email is considered official public record, and so cant easily be stored by an outside provider that may have differing retention or protection policies.
The registry fully supports granular ACLs, the same as the file system. You can see these by running regedit, right-clicking on any key or value, and choosing permissions. You'll then see a very familiar ACL editing screen.
So for example, you can restrict any arbitrary key or value (or entire hierarchy) to only administrators, or any group, or any person.
This is, in fact, how the system ships, with pretty much all of HKLM read-only for non-admin users. Generally, the only sections of the registry that have write-access from non-admin users are the user-hive, ie HKEY_CURRENT_USER, or HKEY_USERS/SID.
In addition, targeted loosening of the ACLs on specific registry keys (with the use of a tool like RegMon), is often one of the things you have to do to make bad-software work under a non-admin user account.
Does this answer what you were referring to, or was it something else?
I'm not going to respond point by point here, as you're right in that running as non-admin does not make you 100% guaranteed safe from a smart, determined attacker.
The point I was trying to make is that it dramatically, hugely, massively reduces your risk of being successfully exploited. And if you are exploited, it drastically reduces the level of damage the attacker can do.
It's defense in depth.
And I know in your end section you were using hyperbole to make a dramatic point, but its really not all that bad in practice. If you run your shops in this way, you are going to experience little to zero issues with anonymous/automated malware (ie, not personally targeted at you by a determined and resourceful attacker).
It is so trivial to find a local escalation in Windows it is not even considered an issue. The consensus of the security community is and has been that if you can run code you can elevate that code. Can you support this? I'm not aware of any outstanding local priv elevation vulnerabilities in XP or Vista. Or any way to trivially escalate from a non-admin user to admin privs. I dont believe its as simple as you're suggesting.
Read this article which was also covered on Slashdot. By default installers run with admin privileges, which means they will be designed to run with admin privileges for the foreseeable future. That means little timmy will regularly download installers and be given the exact same procedure for installing a rootkit as for installing a freeware game of something. Okay, I appreciate the additional information, that clarifies what you are concerned about.
But it should be stated, that installers dont automatically 'get' admin privs unless you give them to them. If little timmy is running as a non-admin (why would you give your 10-year old boy admin rights to your home computer?), then if he tries to run an installer, it just fails, as he doesnt have privileges or an admin account.
So its not like the installer gets an automatic privilege escalation. Its up to you as the admin to give that away or not.
It's not really quite as big of a deal as people are making out, due to the rarity that it would ever work (installing software as non-admin). However, I do agree that its a shame you cant just runas and run an installer as an arbitrary non-admin account.
I would suggest finding a different way to state your concern though, as it reads (to me at least) as if you're saying that anyone running an installer automatically gets privilege escalation from their non-admin account to an admin account.
NT's permissions system is in theory far better than Linux's. The trouble is, Microsoft shoved down a no-security single-user mentality, and APIs to match, on the top of it. The fact that, out-the-box, the theoretically wonderful Windows permissions system is essentially set to "full permissions for everything" (on XP, anyway) Okay, not trying to be too picky here, but this isnt really strictly true.
XP and 2003 have a fairly tightly locked down set of ACLs on the default file system.
However, as long as you run as the local admin, you have default privs to everything (as it should be).
Run as a non-admin, and you'll quickly see that you have write permissions to very little on the file-system outside of your profile.
Okay, I hate to get involved in this love-fest, but two things catch my eye that I think you're mistaken on.
As a policy MS does not fix local escalations in Windows home edition. So it is a minor speed bump for little Timmy to root the machine. I'm not sure what this means, but I dont believe this is correct. Privilege escalation exploits get found and patched a couple times a year. The patch applies to all versions of the OS, since they're all the same core. Are you saying that they release patches but fix the patch so that it explicitly wont run on the Home versions?
Even the architectural flaws that allowed the good ol' shatter attack to work in some rare cases is now quashed in Vista, as lower-priv windows cannot pass messages to higher-priv windows.
Also, as of the current release all installers run as admin, meaning little timmy can root the machine with an installer. I'm not at all sure what you mean by this, but as stated, this is flatly incorrect.
Now there is an OPTIONAL mechanism to allow 'advertised' apps to be run with elevated privs, but this is off by default, and only works on applications that have been 'advertised' to the machine by the domain or system admins.
There is also an optional mechanism to allow all MSI apps to run with elevated privileges, but this is off by default, and can only be turned on by an admin. And its advertised all over the documentation as 'a bad idea'.
User security will not stop a virus from searching your home directory for your tax return and mailing it off to some identity theft. Nor will it stop a virus from accessing the internet to launch DDoS attacks, send spam, or reproduce.
Running as non-admin significantly mitigates many of these, even if it doesnt outright stop all of them.
So yes, a specific malware could still carry its own user-mode smtp engine (some do), but it will drastically reduce its ability to do long term harm.
In user-space, the malware can only run when the user who was infected by it is logged in, and only will survive reboots if it places a shortcut to itself in the Startup folder. And it'll be very obvious there.
In other words, if its restricted to user-mode, it'll be very hard to hide itself and be stealthy.
Plus, a user-mode trojan wont be able to bypass anti-virus, anti-spyware, or firewalls. So if you're using a good firewall that only allows 'known' executables to start other executables or talk on the network, it'll be really obvious something bad is happening.
Plus a user-mode malware doesnt have access to raw sockets, so is fairly limited in its ability to do DDoS attacks. It's not stopped, but its mitigated.
And overall, the malware cant take over the machine and turn it into a bot. A good firewall, leave the machine on auto-patch, and dont run as admin, and your box will be pretty much untouchable. If you then stop using IE altogether (to avoid drive-by downloads/installs), you're going to be largely impervious to data-leakage as well.
I've got to strongly disagree with this. I (and every company I've owned or worked for) have had all users running as non-admin since early in the Windows 2000 days. This includes my personal machine and all work machines.
It works just fine. The only programs I have had consistent problems with over the years is Trillian and WinAmp, but fortunately those are easy to fix with some file & folder acl changes.
Now mind you, there are some occasional times where you have to runas or (very rarely) log in as the admin account. They're mostly installing new software or doing system maintenance.
But thats why you create two accounts, your regular user account and a separate account that is a member of the local administrators group. Then use your local admin account when you need it.
Granted, grandma may not deal with it well without a little support, but for your typical slashdot user, it should be a no-brainer.
Plus when you run xp as non-admin you're pretty much impervious to security issues (as long as you keep the machine patched, but thats fully automatic and brainless).
This would work now, until you need to install anything more complicated than a flash game.
You have a number of needs that surpass installing in the user's home directories:
1. Installing any software to be available to all users. Now technically, a correctly written program on windows will only install its software to/Program Files//, and use user profiles and the all users profile for settings. So this isnt technically modifying the os I guess.
2. System Software. OS patches, firewalls, drivers, etc.
Installing software only on a per-user basis is completely possible now for many classes of applications, but most app vendors dont support it well. You dont need to do global com/dll registration (though often its smart to), you can just ship the component in the same directory as the app. (Of course, shipping app-specific versions of many libraries carries its own set of patching risks, see gzip, etc).
And smart app developers (outside of microsoft) dont use the registry at all, and havent for years. This is of course excepted by software that needs to install services, or register software libraries globally, etc. But even that component can be kept nicely isolated, so you could just move the flat to a new box, and then re-run the os-service setup, and you're good to go.
Depends on the apps though, some have legitimate deep integration needs with the OS, some dont.
Slashdot Mirror
Several significant ones.
1. Whole disk encryption.
Truecrypt can only encrypt a non-system partition, or create a virtual partition on a file.
Vista's bitlocker is whole-disk, as in you cant have access to windows until you've started the pre-loader and entered your password or smart-card.
So the pagefile, temporary files, windows system files, etc are all always encrypted.
One of the only other significant competitors for whole-disk encryption is the commercial PGP product.
2. Key-Escrow (or equivalent through multiple decrypting accounts)
So what do you do when a person leaves their job and doesnt tell you the password? You'll need to be able to get into it and decrypt it, or better yet, give someone else's account access to the volume.
True crypt has a real hacky way to do the latter, which you can see in their FAQ.
Happens all the time.
In your car between clients, want to do some email and catch up.
Sitting outside a business after doing some work.
Sitting in another business that doesnt have wifi or other network you can use.
Sitting in an airport that doesnt have wifi (too damn many even today), or when you dont want to pay $10 for 20 minutes of email.
Sitting in restaurant or coffee shop that doesnt have free wifi (or that you dont want to pay for).
Now I know that not everyone lives the way I do, and so online/offline performance isnt critical to everyone. But just about anyone who primarily uses a laptop because they need one, there's always some place or another where you've got downtime, but no network.
So yes, its not common for home users, but its very common for IT professionals, and managers/PMs/Business Analysts in just about any business.
Webmail using anyone's machine but your own is not useful, as there is no security.
How can you absolutely guarantee that every single not-owned-by-you computer is not compromised and infested with key-loggers, or that the owner could profit from some corporate espionage by stealing your email login?
People say that Outlook is dangerous due to security issues (which havent really been a problem since Outlook 2000), but they'll go to some random kiosk managed by someone they dont know, assuming its even managed at all, and blindly share their user/pass with anyone who's installed a key-logger on the machine?
The problem is that if you want any sort of even mediocre security whatsoever, you have to carry around your own laptop with you.
Otherwise, you're having to trust that every single computer you use to use gmail is managed well enough by its owner that its absolutely guaranteed not to be compromised and have a key-logger (nearly all 'kiosk' types of computers are thus compromised), and that the owner itself would never consider stealing your gmail login.
In other words, its utterly useless unless you carry around your own laptop with you, and at that point, why not just use Outlook.
Because if my shop doesnt already use MySQL, then its adding an entire new DBMS just to support one app. That's expensive.
Most shops settle on one 'utility' db for stuff like this so that they can amortize their maintenance costs across everything they use it for. Think of all the highly specialized functions surrounding a DB server that you've got to do: backup, patch, monitor, upgrade periodically, and generally just maintain it (ie, make sure its tuned right for memory, not running out of disk, has the right firewall ports opened, etc etc).
So if I've already got PostgreSQL or MSSQL or whatever, having to add an entire DBMS just to host one app whose developers couldnt be bothered to use a DAL (Data Abstraction Layer) is irritating, and is often a dealbreaker. It makes using that app much more expensive (in terms of ancillary maintenance costs) than it would have to be if it was just backed by ODBC/JDBC/Pear/whatever, and you could plugin whatever DB you wanted.
It's not politico's making IT policy.
It's IT professionals in the OMB and other fed units making IT policy.
... you lose all the bennies of running the microsoft stack that way.
Additional services like Distributed Transaction Coordinator, Remote Registry Service, Server Service (which exposes the IPC$ share - you can't shut this off anymore), Microsoft Installer, Task Scheduler (which has a long and sordid history of unpatched vulnerabilities), Automatic Updates, Background Intelligent Transfer Service, Computer Browser service, DCOM Server Process Launcher, Error Reporting Service - etc. the list goes on and on. You can shut off most of this crap on a Workgroup machine. A Domain member needs to have a lot of these turned on - and that exposes a lot more surface area to attack. The expertise to determine which services support which functionality; what you can turn off and still get done - is not cheap or easy. Most of these services, you can't google on and get a meaningful answer, nor is Microsoft's documentation always clear. It's not that hard, and would take a competent sysadmin about a day to figure it all out.No department could or would want to run as a workgroup
And thats half the point of a common security config, you've reduced the surface area to a minimum amount.
I havent seen the fed.gov specifics yet ... but I'd bet its basically the same thing that nsa suggests for configuring your boxes.
Things like:
- minimum password lengths
- minimum password complexity
- password rotation
- password strength auditing
- running all users as non-admin
- do not store lm hash
- sign & encrypt all cifs & ldap communications
- do not allow anonymous access to anything (shares, sam, etc)
- X services set to disabled
- host-based firewall running
- anti-virus running
- run services as network service or other non-prived accounts
- etc.
So how does having all the computers configured thusly make them all more vulnerable, just because they're the same?
In every case this makes the system more secure. About the only possible monoculture issue that could come up is the a/v and firewall. If they're all by the same company and they all suffer from a vulnerability then there's a weakness. But this is probably already the case anyway, as the big fed departments all will sign big contracts with an a/v vendor for cheaper prices.
Did you not read the article?
... Microsoft is not giving anyone permission for anything.
This has nothing to do with Microsoft.
I'll spell it out.
Some IT folks in fed.gov have come up with a security policy (ie, group policies, registry tweaks, acl changes, user-rights changes, etc). They are saying that they will be running all vista machines with that exact security policy enforced.
They are then saying that to be able to big on software contracts, the ISV must certify that their software will run on Vista configured with this policy.
Microsoft is not involved in any way.
It's not Microsoft creating the security policy. It's not Microsoft creating a new vista sku. It's not Microsoft creating a certification program to sign & cert tested software. It's NONE of these things.
So to be crystal clear here
If you could be bothered to read TFA you'd see that.
Could you not even be bothered to read the article?
... nothing.
Microsoft has _nothing_ to do with this. Let me repeat
It is a 'secure configuration', not a different sku from microsoft.
In other words, its vista with a specified security policy applied to it.
And then ISVs must certify that their software runs on vista configured in that manner.
RTFA for ignorance' sake.
"Long story made short - larger vehicles will always consume more energy then smaller vehicles. Sorry Hummer owners, but it's true."
While thats technically true its a bit trivial. Many, many people require a larger vehicle for any number of reasons. Ever try to haul camping gear and a trailer full of quads to the sand-dunes in a prius? Ever try to sleep in the back of your prius in the forest (not sure if its possible for most, but it would be way too small for me)?
"Don't forget the fact that larger engines consume more gas. They are designed to produce a larger peak power and as such, require stronger, heavier parts. Moving heavier parts requires more energy thereby increasing fuel usage."
Not really. A larger engine is typically used to provide more torque, which is required for hauling, not for more peak power. It's often more efficient (economically) to use a smaller, very high-strung (ie, turbos, etc) engine to producer higher peak power. Usually thats done by designing the engine so that it can run to a higher peak rpm. In that scenario (high-rpm) big engines do particularly poorly, as there's that much more steel to slop back and forth.
But increasing displacement is really the only way to increase torque (in general), so therefore you have larger engines in trucks, SUVs, etc where torque is more important than peak horsepower.
Okay, this requires a response. Do you really believe this nonsense on the page you've linked?
Okay, so lets turn on our logic circuit (ie, brain), and think about this thoroughly, and not just regurgitate what someone tells us.
MPG (Miles Per Gallon) is only one measure of impact to the environment and overall 'cost' of cars.
For a MPG rating to be meaningful between two vehicles, they have to share some common traits:
1. Similar weight. The heavier the car gets, the lower your MPG gets. But many vehicles (ie, trucks) require some of that weight for beds and towing.
Your typical family car weights ~3000 pounds nowadays, compared to the model T which weighed 1200 pounds for the open roadster, and a bit more for the enclosed car.
2. Safety. Massive federal regs in the US have required massive changes to cars that increase safety. We're all very happy about this. However, this tends to make a car much heavier (see #1 above).
Do you want to bet what is going to happen if you have a head-on collision with a modern family sedan and a Model-T? Which car would you want to be in?
3. Power. The market (ie, buyers/people) want more power in their cars, and they're willing to trade fuel-economy for it. Plus it take alot more power to push around a 3000 lb car than it does a 1200 lb car.
For comparison, the Model-T produced ~20hp (somewhere between 1/5 and 1/10 of the family sedan of today), with a 2.9L 4-cylinder, 4-stroke engine.
4. Pollution. Anti-pollution technologies (lean-burning, catalytic converters, etc) all reduce power and add weight.
How much noxious chemicals do you think the Model-T was pumping out of its tailpipe and oil-dripping from the engine? Compare that to the modern ULEV or better car, where you can almost use the exhaust for breathing-air its so clean.
So even if they really dont get any better fuel economy out of the 'typical' car now than then, you're getting 5-10x the power, and 2-3 times the top speed at twice the weight and an order of magnitude more safety. All that with practically zero emissions, and massive comfort, air-conditioning, zoned-temperature-control, and a dvd-player in the back-seat.
So miles-per-gallon is only one dimension that you care about, there's also miles per death, average-miles-per-hour (more power equals go faster equals less time spent driving equals more time spent living life), emissions-per-mile, and mile-pounds per gallon.
So to tie us back to the grandparent, yes, there really has been massive amounts of progress. Just because it isnt in a naive analysis of miles-per-gallon doesnt mean it isnt meaningul, it just means that its not what the market and governments care about. Other factors are much more meaningful.
This only works for the very smallest of the small colleges & universities.
My alumn, for example (which is not a particularly huge school), runs at 50,000-60,000 email accounts (students, staff, affiliates, etc), at 500MB each.
So thats ~60TB of data. And given the need for uptime and reliability, this means a very expensive highly redundant SAN, plus load-balanced (ie, clustered) front-end servers. Plus backup.
Figure at least a few hundred thousand dollars per year, in (amortized & ongoing) hardware costs and costs for staff time for updates, maintenance, support, etc. And thats with a full open source email stack.
So to answer your question, running email for a mid or large sized university is very expensive. Even more so given how fundamental email becomes to most organization ... try taking down the email server for a university and see how much work gets done.
But anytime you are spending that kind of cash on non-core (ie, not education or directly supporting education) service, you're obligated to at least consider alternatives.
Mind you, I dont think that outsourcing email is a good idea for Universities. And many universities cannot do this, as staff email is considered official public record, and so cant easily be stored by an outside provider that may have differing retention or protection policies.
The registry fully supports granular ACLs, the same as the file system. You can see these by running regedit, right-clicking on any key or value, and choosing permissions. You'll then see a very familiar ACL editing screen.
So for example, you can restrict any arbitrary key or value (or entire hierarchy) to only administrators, or any group, or any person.
This is, in fact, how the system ships, with pretty much all of HKLM read-only for non-admin users. Generally, the only sections of the registry that have write-access from non-admin users are the user-hive, ie HKEY_CURRENT_USER, or HKEY_USERS/SID.
In addition, targeted loosening of the ACLs on specific registry keys (with the use of a tool like RegMon), is often one of the things you have to do to make bad-software work under a non-admin user account.
Does this answer what you were referring to, or was it something else?
I'm not going to respond point by point here, as you're right in that running as non-admin does not make you 100% guaranteed safe from a smart, determined attacker.
The point I was trying to make is that it dramatically, hugely, massively reduces your risk of being successfully exploited. And if you are exploited, it drastically reduces the level of damage the attacker can do.
It's defense in depth.
And I know in your end section you were using hyperbole to make a dramatic point, but its really not all that bad in practice. If you run your shops in this way, you are going to experience little to zero issues with anonymous/automated malware (ie, not personally targeted at you by a determined and resourceful attacker).
I've done it and seen the proof over the years.
Thanks for the links ... I was not aware of these ... I'll look into it a little deeper
But it should be stated, that installers dont automatically 'get' admin privs unless you give them to them. If little timmy is running as a non-admin (why would you give your 10-year old boy admin rights to your home computer?), then if he tries to run an installer, it just fails, as he doesnt have privileges or an admin account.
So its not like the installer gets an automatic privilege escalation. Its up to you as the admin to give that away or not.
It's not really quite as big of a deal as people are making out, due to the rarity that it would ever work (installing software as non-admin). However, I do agree that its a shame you cant just runas and run an installer as an arbitrary non-admin account.
I would suggest finding a different way to state your concern though, as it reads (to me at least) as if you're saying that anyone running an installer automatically gets privilege escalation from their non-admin account to an admin account.
Hmmm, that is fairly horrible. Thanks for the example.
XP and 2003 have a fairly tightly locked down set of ACLs on the default file system.
However, as long as you run as the local admin, you have default privs to everything (as it should be).
Run as a non-admin, and you'll quickly see that you have write permissions to very little on the file-system outside of your profile.
Even the architectural flaws that allowed the good ol' shatter attack to work in some rare cases is now quashed in Vista, as lower-priv windows cannot pass messages to higher-priv windows.
Also, as of the current release all installers run as admin, meaning little timmy can root the machine with an installer. I'm not at all sure what you mean by this, but as stated, this is flatly incorrect.Now there is an OPTIONAL mechanism to allow 'advertised' apps to be run with elevated privs, but this is off by default, and only works on applications that have been 'advertised' to the machine by the domain or system admins.
There is also an optional mechanism to allow all MSI apps to run with elevated privileges, but this is off by default, and can only be turned on by an admin. And its advertised all over the documentation as 'a bad idea'.
Some references:
Installing a Package with Elevated Privileges for a Non-Admin
Note that this worked substantially the same in XP.
Because if an automaker has faulty parts or design in their car, people die or get injured.
Whereas if MS produces a bad OS, at worst there may be some limited financial loss.
But no one dies or gets hurt. It's not even in the same class of issue.
Running as non-admin significantly mitigates many of these, even if it doesnt outright stop all of them.
So yes, a specific malware could still carry its own user-mode smtp engine (some do), but it will drastically reduce its ability to do long term harm.
In user-space, the malware can only run when the user who was infected by it is logged in, and only will survive reboots if it places a shortcut to itself in the Startup folder. And it'll be very obvious there.
In other words, if its restricted to user-mode, it'll be very hard to hide itself and be stealthy.
Plus, a user-mode trojan wont be able to bypass anti-virus, anti-spyware, or firewalls. So if you're using a good firewall that only allows 'known' executables to start other executables or talk on the network, it'll be really obvious something bad is happening.
Plus a user-mode malware doesnt have access to raw sockets, so is fairly limited in its ability to do DDoS attacks. It's not stopped, but its mitigated.
And overall, the malware cant take over the machine and turn it into a bot. A good firewall, leave the machine on auto-patch, and dont run as admin, and your box will be pretty much untouchable. If you then stop using IE altogether (to avoid drive-by downloads/installs), you're going to be largely impervious to data-leakage as well.
I've got to strongly disagree with this. I (and every company I've owned or worked for) have had all users running as non-admin since early in the Windows 2000 days. This includes my personal machine and all work machines.
It works just fine. The only programs I have had consistent problems with over the years is Trillian and WinAmp, but fortunately those are easy to fix with some file & folder acl changes.
Now mind you, there are some occasional times where you have to runas or (very rarely) log in as the admin account. They're mostly installing new software or doing system maintenance.
But thats why you create two accounts, your regular user account and a separate account that is a member of the local administrators group. Then use your local admin account when you need it.
Granted, grandma may not deal with it well without a little support, but for your typical slashdot user, it should be a no-brainer.
Plus when you run xp as non-admin you're pretty much impervious to security issues (as long as you keep the machine patched, but thats fully automatic and brainless).
This would work now, until you need to install anything more complicated than a flash game.
/Program Files//, and use user profiles and the all users profile for settings. So this isnt technically modifying the os I guess.
You have a number of needs that surpass installing in the user's home directories:
1. Installing any software to be available to all users. Now technically, a correctly written program on windows will only install its software to
2. System Software. OS patches, firewalls, drivers, etc.
Installing software only on a per-user basis is completely possible now for many classes of applications, but most app vendors dont support it well. You dont need to do global com/dll registration (though often its smart to), you can just ship the component in the same directory as the app. (Of course, shipping app-specific versions of many libraries carries its own set of patching risks, see gzip, etc).
And smart app developers (outside of microsoft) dont use the registry at all, and havent for years. This is of course excepted by software that needs to install services, or register software libraries globally, etc. But even that component can be kept nicely isolated, so you could just move the flat to a new box, and then re-run the os-service setup, and you're good to go.
Depends on the apps though, some have legitimate deep integration needs with the OS, some dont.