Slashdot Mirror
Longhorn to use UNIX-like User Permissions
destuxor writes "After years of Windows users abusing administrative accounts out of necessity, Microsoft promises that Longhorn will make better use of user permissions in what sounds exactly like what UNIX/Linux users have been doing for years. Hopefully this will fix the long list of applcations that cannot be run by a Least-Privilege User Account (LUA) while giving a much-needed security boost. Too bad "MS-root" can't watch over your grandmother when she opens emails."
Whilst this is a step in the right direction, Id be willing to bet that Microsoft will put a hefty fee on the LUA Pricniples program, putting it out of the reach of a lot of smaller software houses.
If this is the case, then users will once again become used to just allowing any old piece of software to install with higher privileges, totally defeating the purpose of this.
How many people do you think abort the installation of unsigned drivers, even when XP warns them that they are unsigned. I'd presume it is a very high percentage.
You can lead a horse to water, but you cant make it drink.
I think that it's a good start and may well make a big difference in companies which use Windows as their desktop platform and have system administrators who can control user accounts.
This section from the article seems to have a good point: A strictly enforced LUA model could make it harder for worms and viruses to take over Windows systems. But Microsoft may have a tough time changing user and developer behaviour, even with new features that support the LUA regime in Longhorn, experts warn.
On home systems, we still currently have enough problems trying to convince people not to open dubious attachments, or with people giving sites permission to install practically anything on their machines. It will take a big shift in attitudes (or Microsoft forcing the user to jump though hoops) to make many home users have anything but admin-privilege accounts.
It's about damned time this issue gets addressed. Every day at work I have to fight with this M$ limitation. Chief among the offenders are:
- Kodak Share software
- Autocad
- Any serial port emulation program
- PowerDVD
Most users must be elevated to Power User status on their machines to allow them to do anything nowadays, while there are plenty of programs (like the ones listed above) that will malfunction or simply refuse to work with anything less than full Admin rights. Sometimes, I have no choice but to give a user full Admin rights...I grind my teeth as I do so, knowing full well I'll be called to disinfect the machine of countless spyware programs within weeks, if not days.
____
~ |rip/\/\aster /\/\onkey
Microsoft also proposes application manifests, which allow developers to define the permissions an application needs to operate properly
I recall a few years ago when all applications even MS Office came with this type of documentation so that Netware administrators could install the software and configure the "rights" properly.
I had recently encountered a few Windows applications where permissions were a problem and I was reminiscing about just that. Serendipity?
The permissions will permanently be set to 777.
The problem has never been a lack of permissions in NTFS, just that no one uses them well.
This might not change much, windows users are generally lazy. I see most people will just log in as an administrator and stay that way forever. The article didn't mention how easy it would be to switch to an administrator either like unix's su. No matter what microsoft does security will always be a huge problem, users don't want to change they like it easy.
No the Microsoft permissions in Longhorn will be different from Unix permissions... :-)
They'll be patented.
Windows security model is better than traditional UNIX permissions. There's no way they'd throw that away.
It sounds more like they'll have secure default permissions, e.g. making \winnt non-world-writable. This isn't "UNIX-like", just not stupid.
This has been a long time coming! It's not that hard to implement but can add so much security and stability!
I wonder if MS is going to follow their good old track record of bending and breaking all the rules. If the permission system is full of exceptions then in a short time it's going to be the same problems we're seeing now.
If they are going to steal someones security model then they should steal one that has some benefits.
:D
What? You wanted them to steal the security model from RiscOS? I think they already tried that with Win98
We steal their good stuff (hey! it might happen!), they steal ours, everyone steals from Apple. Building on existing good ideas is called progress.
Beep beep.
I think per-file permissions are a major reason why Linux hasn't been accepted on the desktop. It'll be interesting to see if Microsoft can match that level of security without making it so much of a hassle.
well, it will once MS finally patents them like they did sudo.
http://taint.org/2004/08/20/024522a.html
--
Check out my music video!
How will we ever know? Are there any 3rd parties that do code audits on proprietary software?
--
Evan (Really nifty language)
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
"here at microsoft we invent things. Linux is still in the process of copying"
So now who copys what?
See pictures of tits
"Microsoft promises that Longhorn will make better use of user permissions in what sounds exactly like what UNIX/Linux users have been doing for years."
You misspelled Macintosh. As any Mac user could tell you, ALL innovations were originated by Apple. Since Mac users hate the fact that anything was originally developed by anyone other than Apple, I will now use their bizarro logic to make my case.
1 - BSD was derived from AT&T's Unix. The settlement prevents BSD from legally being called "Unix"
2 - AT&T's Unix predates Linux.
3 - Apple's OS X uses BSD.
There you have it. I don't think I can get any clearer than that.
Mr. T pitied this fool on 27 July 1992.
The permission mechanisms in Windows NT/2k/XP are pretty flexible. Unix is only just migrating from the old user/group/world permission set to access control lists, something that is readily available for just about everything in the Windows operating system, from files to individual registry entries.
The problem with Windows permission management is that a) it is completely hidden from the casual user, b) there are no guidelines how applications can be made to work with restricted privileges and programmers are too lazy to figure it out themselves and c) the default XP install makes everybody an admin, so there is very little incentive for application programmers to get it right.
.... somewhere down the road we discover that Microsoft is borrowing a lot of readily available *BSD (or even Linux) code for some or all of the operating system core? Whether they admit it or not is beside the point. Whether Apple has done it first or not is also beside the point.
And what if, either through using a UNIX core, or taking what's there and advancing it to the next level, Microsoft really gets it right this time? They're spending a lot of time on it.
Would we still hate them?
do() || do_not();
While this has been a long time in coming, problems are bound to accompany a change of this large a scale. I see the biggest problem being older apps that do the job, but aren't under development anymore. As well, it would be great if MS could implement something that follows along the same lines as the su command for *nix. Just a quick userswitch at the command line, install a program, and bam, done.
Expectations are for the unprepared.
I'd like to add that I hope that some of the software developers will start to consider that people will be running their software under another account other than "owner". I have a game, that no matter what I do to the permissions, will not run under any account other than the owner/administrator. /. regarding Windows security and permissions and I haven't had my machine corrupted - yet (knocks on head) Knock on wood.
I'd also like to point out that I've been following all of the suggestions and tips on
Thanks guys!
But here's something that worries me more about manifests:
Based only on this part, it appears that an application manifest must be published by an entity that can afford three figures USD per year for a code signing license. Developers of free software and proprietary freeware often cannot afford this annual fee. My worry is that Longhorn Home Edition may not permit users to install customized deployment manifests, locking users into using only programs with an application manifest, that is, proprietary commercial software.
...maybe now someone could introduce them to the concept of mount points?
The gift of death metal does not smile on the good looking.
I guess what they'll have to be innovative at is implementing it in such a way that it'll be secure, without breaking old software, but breaking old user/developer habits which caused the mess that requires them to implement this now.
AC comments get piped to
Those who do not understand Unix are condemned to reinvent it, poorly.
After reading the article *gasp*, I wouldn't say Microsoft is moving towards a UNIX-like security system. Rather they are moving away from a stupid security system.
There's nothing inherently UNIX-ish about not giving normal users administrative privileges. Unless you're defining UNIX as any multi-user operating system. The idea of limiting normal users is standard in any decent multi-user operating system.
From the article:
"90 percent of Windows software can't be installed without administrator access to Windows"
This is a problem?
Installing software is an administrative task, not a user task. Software installation *should* require admin access.
Just one more example of MS not understanding the difference between administration and use.
This isn't Windows switching from their ACL model to a UNIX permission model.
/finally/, forcing the issue.
One, they are pushing for 3rd-party developers to finally stop requiring simple apps like kid's software and low-end desktop publishing to be run with escalated privileges.
I mean, these application developers have had since '98 or '99 to work this out. But Window's lax defaults and lack of user education didn't force the issue. Microsoft is finally,
Two, it is Microsoft finally realigning their default ACLs to be at once more secure and more common sense.
It makes no sense for a home user to not be able to control their power settings or change their system time unless they have escalated privileges.
Really, this isn't so much Windows following UNIX as it is Windows following OS X.
Finally, and this is IMHO, going to a permission model would be a *huge* step backwards. I know UNIX die-hards will flame me for this, but it is my experience that ACLs are much more flexible and lucid than permissions.
obviously no deficiencies vs. no obvious deficiencies
Does this mean that Microsoft prefers the Unix approach?
Or does it mean that Microsoft finally gave up on the Windows code base, and is now using a BSD foundation, with a Windows front-end, as the basis for Longhorn?
and to throw away that crusty C: D: E: drive notation and to use a single rooted hierarchy like the rest of the civilized OS world.
Unix permissions _do suck, they're too simplistic and ACLs solve a lot of the problems inherent to it. For example, if I want to define a class of groups where each group defines a set of people allowed certain permissions to a directory, recursively, there's simply no way unless you use a filesystem that has an ACL extension (or something like XFS which has ACLs built in).
The article poster's saying "Unix Permissions" was being misinformative; Windows will never use the setuid-user-group-world style permissions, it has an ACL-like system. I think what's really meant is that this system will actually be USED in the future, it's pretty much ignored right now for most Windows desktops. As I read this, Microsoft will just be actually enforcing and organizing their own system -- which is a good idea.
If you say "here goes my karma" I will bite you!!!
People that spout crap like "But I'd like to exclude one specific user" or "more than one group is allowed to access this file" just don't get the point of grouping. Sure, you sometimes just need complex access policies, but those rules almost always apply to information systems where the access rules are easily put in a database. You don't need ACLs in operating system file systems. I'd say current MS' access policy is written up by a failed techie that way promised a middle-management job and fell for the evil trap.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
http://www.freepatentsonline.com/4135240.html
Inventors: Ritchie; Dennis M. (Summit, NJ)
Abstract: An improved arrangement for controlling access to data files by computer users. Access permission bits are used in the prior art to separately indicate permissions for the file owner and nonowners to read, write and execute the file contents. An additional access control bit is added to each executable file. When this bit is set to one, the identification of the current user is changed to that of the owner of the executable file. The program in the executable file then has access to all data files owned by the same owner. This change is temporary, the proper identification being restored when the program is terminated.
Assignee: Bell Telephone Laboratories, Incorporated (Murray Hill, NJ)
Application Number: 377591
Filing Date: July 9, 1973
Publication Date: January 16, 1979
Seriously, the security community as been screaming about this for years just so MS could have parity with other multi-user systems. Of course, the big issue will be pushing other software vendors to compliance. Regardless, at least average users may finally not (by default) browse the web with an admin priveleged account. That should cut down on a lot of the malware issues that are encountered.
Summary of above post... "There's no way to do x, except for the way to do x"
Just as the login process forks and drops its root privileges before running your shell, the file manager or window manager would fork and drop its full user privileges before running an application that was supposed to wear a certain hat.
Please, get over yourselves ... how is running with a LUA *nix like?
I'd love to blame Microsoft for their own operating system problems, but really, the blame is mostly on the third party developers.
It has been this way from the beginning... as far back as I can see, developers skirted the BIOS because BIOS calls were too slow -- that was back when the BIOS was part of the OS. This is not a Microsoft problem, but it adds to understanding of how the culture evolved. "Forget about standards and interoperability, we need to deliver performance!" The error in judgement has been costly.
Today developers continue to write code that uses and exploits bugs and irregularities in the MS Windows operating system environment. If I learned nothing else from reading the comments found in the Windows Source code scandals, I learned that Microsoft became obliged to add code to emulate bugs and irregularities for specific applications to continue to run properly. In a perfect world, the app writers would write code using the APIs as documented. (And when bugs and irregularities were found, Microsoft would FIX them to discourage developers from utilizing the strange or buggy behaviors)
Developers should be mature enough to realize that any bug or irregularity found in an OS API should be considered subject to change and could break their software once it is fixed. It kinda bugs me that these "paid professionals" were and continue to be so short-sighted.... (meanwhile, these Open Source Amateurs rely almost exclusively on documented API functions and features simply because bugs and irregularities are often fixed quickly enough that to write code against them would mean they would need to update their code AGAIN.)
I think this kind of speaks volumes about where the real weakness in commericial software development lies -- in the motivation.
Thank God. I can't count the number of times I've had to deal with the stupid permission settings in Windows. Even for a simple thing like sharing files and folders over a home network. Their system is so convoluted and just completely stupid - pointing and clicking through various menus to set attributes... conflicting attribues... and all kinds of other crap. I was trying to set up access permissions on a home networked machine whereby it would authenticate against another machine on the same network. But you can't do that with "Workgroups". Only "Domains". All I have is a small home network of 3 machines - I have to set up a Domain Controller now? Why the distinction? All the "features" that microsoft has for their permissions system are simply inane and counterintuitive. To keep myself from pulling out all my hair, I just set the permissions to Everyone so that everyone and their mom on the home network can access the folder. But since it's just me at home, that's alright. And even then I've had trouble with that.
I'm glad they've decided to scrap it and move to a more unix-like. The next thing they should do is change their "automated task scheduler" tool. Make it more like cron. "at" just sucks.
Vivin Suresh Paliath
http://vivin.net
I like
on Windows - WHY?
I thought they wanted normal users to use Java.
This doesn't solve all problems for Microsoft, just changes them.
While this will be a certain benefit to corporate environments with IT security policies and IT departments to come install/upgrade software for employees while at the same time ensuring that new version of FreeCell you got from a friend doesn't infect the whole corporate network, the issues become more troublesome for home users.
A home user will either end up running their system as an Administrator, thus circumventing the access permissions model, and/or they will become frustrated with the inability to install/update/access/delete files on their own computer.
How many times has the home user faced a property configuration wizard that tells them to contact their "system/network administrator" for more information.
My mother is not a "system administrator", but yet, to change her ISP, she had to put on that hat or call me to talk her through it.
No disrespect to Linux, but Microsoft would do well to study Apple's model for system security on a home implementation. Apple has, successfulyl in my opinion, abstracted much of the user security model to allow the home user to know nothing about CHMOD while still providing appropriate security when needed - like entering an administrative password (SUDOing the application) for installations and upgrades.
Last on the list of needed changes to the windows security model is to provide far more robust error/exception handling when a user does something like tries to rename a file that is open. Consider this closing argument:
"The file cannot be renamed because it is in use by another application."
versus
"The file 'foo.doc' cannot be renamed to 'bar.doc' because it is opened by 'Word.exe' would you like to:
- Cancel the renaming
- Save the document changes in Word and rename the file
- Discard the document changes in Word and rename the file"
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
After all, the next Windows will be a version of BSD, a rip-off of Mac OSX. Claims of BSD's death are greatly exaggerated.
The Uncoveror: It's the real news.
The problem I've always had with Windows permissions is that it's damned-near impossible to debug permissions problems. After two or three attempts with completely uphelpful error messages, I don't have the time to figure the exactly proper config, so Full Control it is.
If it were easy to tell what the problem was, it would be easier to have a secure system.
Mike
You have to be root to install almost anything.
You have to be root to mount a CD-ROM, USB device like a dongle or camera, SMB share or floppy.
You have to be root to burn a CD.
Now, everyone is going to start screaming that the above trollishness is bogus but, it isn't. Sure, you can easily get around most of this stuff and many distros do. How? They get around it by either giving world writable access to the device or by SUID on the application. It's really no different.
Yes, but will you still need administrator privileges to do basic tasks like defragmenting the disk? Where I work, I pretty much had to steal the local admin password (though nobody would, or does, mind that I have it) to get some much-needed defragmenting and spyware removal taken care of on some of our work machines. The latter will easily be taken care of (without discussing fake password dialogs), but not being able to defrag is a bitch.
It would be cool if it didn't suck.
Microsoft already uses BSD code which, which they can do legally due to the non-viral nature of the license.
If Microsoft were to just take some cash they have in the bank, buy Apple, and port OS X over to the intel PC, this whole Longhorn thing would be fixed.
Microsoft could deliver a great OS that is secure, does everythng they have been promising in Longhorn (almost) and, pardon the expression, "just works"
I would not like this being a Mac user, but it would fix the embarassing Longhorn problem.
Cheers
* Carthago Delenda Est *
They don't need permission.
The patent has expired.
In reality that is what drive naming convention does. Especially using F: for a networked folder \\filer\production Behind the mask of C/D/E could be the \\devicename\partition\ Just windows gives you the convience of the drive name.
----- You know you have ego issues when you register a domain in your name.
try googling for ms lua
You've thrown the fish in reverse. What would you do to find pages about the Lua that isn't Microsoft's new permissions strategy?
You're completely correct. This is extremely annoying.
I recently setup a computer for my 4 year old, most of what she does on it is watch her DVDs. I was totally puzzled as to why she couldn't watch videos on her account while running on Windows 2000.
You get some weird error, so I had to guess it had to do with permissions. I have to login as administrator to let her play DVD movies! This makes totally no sense!
- sigs are for wimps.
I can easily see Microsoft patenting this technology once they have it implemented.
This can only further limit other OS's.
To me it feels more like a race between MS and OSS programmers to get the technology out there to be 'previous art' before we get shut out in the cold by our own legal system.
Get paid to code OSS
"Microsoft is also weighing a logo program, akin to the Windows logo program, that will grant special status to applications that comply with LUA principles, he says."
so they're trying to stop programs from having administrator access on the machine by... giving them special status on the machine? either they're solving the problem by making a new problem or they're solving the problem by re-creating the same problem!
...all software could install as easily and permanently as spyware does. If only I could use VX1 for the accounting department instead of the current software. It's got to be the most fragile and breakable waste of electrons ever developed. Hire some of those spyware making whores and make a damn program that does require Zeus himself to install it, and doesn't shit itself every time you, god forbid, run another program at the same time.
Unix permissions are actually better anyway because they are much easier to work with. It's very easy to write shell scripts that deals with user/group/other permission, see what the permissions are in output from ls, modify in GUI dialogs (see Finder's Info panel for example). If also lets the entire be specified in a fixed-size integer in the inode, which makes file access faster.
... with the + to indicate ACLs are present for the file.
What's needed is old unix permissions + ACLs to handle the exceptions. So the ls output might be: drwxr-xr-x+
Sure, this is a step in the right direction, but it will have zero impact on most users, for two reasons.
1. Most users will just log in as an admin and stay that way forever. Far easier and quicker than typing a password every time you want to install software.
2. Social engineering. By which I mean a pop up box saying "type root password here to see Paris Hiltons tits!". If Joe Sixpack actually used Linux, it would be no more secure than windows, because he would dish out that password every time a dialog asked for it. Or he would get so tired of typing it that he would resort to point 1.
"I realise this is not a very popular opinion but it's the truth, and there for needs to be said" -Bill Hicks
The ones that annoy me the most are applications under Windows that, when installed using an administrator account, "Fix" the permissions on my filesystem for me. I believe the software that came with my old Canon PowerShot (A40?) did this so it could store pictures in the program directory. I mean, ferchrissakes, there's even a bloody "My Pictures" directory that's writeable by the user!
Or go a step further and remove the requirement for the average user to deal with the clumsy and confusing file-and-folder metaphor. Which, admittedly, both Windows and OSX are edging towards.
Rgasuya aata! : I have been coding Perl and cannot tell where my fingers are now!
people like my stupid brother will just run as root 100% of the time...
i explained to him that if he can install software that makes system wide changes then malware and viruses can too, he is either too lazy or does not want to be bothered with the inconvienence of typeing in a password to install software and just wants a point & click instant gratification desktop environment...
Politics is Treachery, Religion is Brainwashing
Sometimes the convenience of not having to mess with permissions seduces developers to the dark side.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
The same could be said about Linux:
Geezo! How many features from NIX systems are they (Linus and crew) going to integrate into their new OS? Why don't they just release their own (BSD, UNIX) distro and face facts.
# cat
Damn, my RAM is full of llamas.
Windows XP does currently enforce these ACLs. The trouble is a lot of users log on as administrator. A lot of software has been written without sufficient foresight or ability (e.g. developed under Win9x without paying attention to NT) and so doesn't function due to assumption that it can write to any part of the file system or registry, etc. Another thing that discourages users from running a limited account is that some things cannot be adjusted - the most common complaints being power and time settings.
Please tell me how I can make Q:\some\silly\directory appear to look as if it is named C:\blah\my_symlinked_directory without copying the files?
Microsoft calls linux a design based on old technology that is hardly innovative.
However, when MS borrows a feature from Unix, it's innovation!
Too bad "MS-root" can't watch over your grandmother when she opens emails.
Well, the UNIX-like permissions should mean she has to chmod u+x before running the attached virus. Who can be arsed doing that?
Follow me
It doesn't matter what security microsoft integrates. It will be defeated with a simple email attachment, or a popup saying "click here for hot girlz"
...but getting older programs working in XP was bad enough. Something like this is probably going to break 3/4 of the old Windows software out there, a nightmare for those of us in the corporate worlds. Cause, you know, Sue in Financials has 10 years worth of expense reports locked up in PeachTree Accounting 4.4 for Windows 95 and doesn't see why she should use anything else, and Doug in Facilities has a master key database in dBase 2.5 for DOS that nothing on the fucking planet can read any more.
Ugh, I'm already seeing the problems.
I think Microsoft needs a cattle prod for their Longhorn, to get it out the door.
Nice to see they're considering adding features added to other OS's 20 years ago, though.
+++OK ATH
It's nearly impossible to do anything useful as a normal user on Windows. Pretty much everybody seems to have to be a Power User to get anything done.
.NET? Isn't it a VM? What exactly is what requires extra privileges here? Under Linux gdb doesn't need any as far as I can see.
Say, why is it that I need special privileges to debug my own programs, made in VS
You misspelled 'inconvenience'
Linux is not Windows
Please please please can it have a case-sensitive file system too?
# cat
Damn, my RAM is full of llamas.
Let's not harass MS if they really are going to adopt unix-ish anything in Longhorn.
Typically, companies like MS identify that some other product has something bettter but they won't adopt it because that would be (a) admitting it, (b) giving credence to their competitor, and (c) reducing lock-in.
Think about how hard it is to get the Linux community to do things in a Windows like way.
So, there is much to abuse MS over; for this they should be congratulated (if they really do it in that way).
Oh really, just how do you know that?
Someone mod this guy up. Slashdot readers who actually believe this write-up must have absolutely no experience with NT permissions or working in an NT corporate environment. NT's security sub-system is *incredibly* fine-grained, and light years ahead of anything Linux is offering. But that won't stop people who've never used it to stop complaining about it, will it? Bahhh!!!! Sheep.
Microsoft is excellent at deflecting criticism by promising fixes, then delivering what are only modest improvements.
When Microsoft software has an obvious problem that competitive software does not, the general pattern is that a) Microsoft claims the next release will fix it; b) the next release falls far short of a fix but is nevertheless a noticeable improvement; c) applause from Microsoft fanboys drowns out those would observe they still haven't achieved parity with the non-Microsoft state-of-the-art.
Since Microsoft users live in a sealed universe--they're too busy keeping up with security patches, changes in API's, and evolving purchase and licensing plans to have the time to ever use any non-Microsoft software--Microsoft gets away with this pattern of "big promise, partial delivery"
Complaints about Windows 3.0 instability were met by the assertion that you "would never see a UAE in Windows 3.1."
Complaints about FAT fragmentation were met by assertions that NTFS would not require defragmentation.
Comments that Windows 3.X was far less usable than the Mac OS were met by assertions that Windows 95 would be just as good as the Mac.
Complaints that installing software under NT 3.x were met by assertions that NT 4.0 would not require rebooting....
"How to Do Nothing," kids activities, back in print!
You can do everything you want using Group Policy objects. Like another poster said , the problem is that it's hidden from the user and basically inaccessible from windows XP home. The other problem is the way it is implemented. Local Group Policy can not be applied to individual users or groups without resorting to cheap hacks. Even when you do the ACL trick you can only get Local Policies for 2 different users. The functionality for multiple Group policies to apply to multiple users groups and computers is there, It is just restricted to using over an AD domain. Obviously this was part of the plan to boost sales of Windows 2000. The point is the only way to get restrictive granularity on users on any given Windows machine is to invest in a Windows server , setup Active Directory and force users to log on to the DC. However you still have the Local User policy problem which automagically applies when there is no Domain Policy to be forced. Obviously the ability is there , it just needs to be implemented on all levels locally and over the wire. They could proaby do it tomorrow with a patch.
No matter where you go , there you are.
I'd also like to point out that I've been following all of the suggestions and tips on /. regarding Windows security and permissions and I haven't had my machine corrupted - yet (knocks on head) Knock on wood.
/. suggestions and installed Linux. No knocking on wood needed.
No wonder, you followed
Congratulations!
LOL
http://shell-shocked.org/article.php?id=284
My last experience with windows permissions was very strange.
You have windows SHARE permissions for network shares. and then you have FILESYSTEM perms for local lusers.
UNIX there is no distinction getween share and filesystem...
Furthermore in windows, i setup some strict NTFS perms on files, which after i reinstalled the OS (preserving said partition and perms (full control to admin only), the new system said (as admin) "you do not have permission to access this folder, please contact your system administrator."
I screamed, bitched and moaned, tried my damndest to get the files out of there to no avail. Now I keep everything on *nix boxen anyway, perms are set nice and strict there.
Logistical Chaos Officer http://www.slagg.org - LAN Gaming in Sarasota FL,USA
Too bad for him being stressed over the extra considerations he must take into mind to watch DVD movies at work. LOL
Those who do not study Unix are doomed to reimplement it --- poorly.
We use PowerDVD 5 on our work systems, which we lock down to the nth degree. Our users do have Power User, but they are not permitted to be local administrators.
M$ to drop Windows in favor of Linux.
Power to the Penguin!
Does there even exist a PC operating system that can ask the application that is holding a file open to close a file in this manner? I'd almost be happy with "The file 'foo.doc' cannot be renamed to 'bar.doc' because it is opened by 'Word.exe'. Please close the file and try again."
Let there be no more remarks about how Open Source never innovates and is always copying Apple or M$...
.
...
I've long expected that the next Win would become more *nix like. They want some of the *nix geek acceptance apple found when they created Darwin and OSX
What remains is how far will they go - fully embracing the ethic might be upset their business model.
"
To do the Unix philosophy right, you have to be loyal to excellence. You have to believe that software is a craft worth all the intelligence and passion you can muster. . . . Software design and implementation should be a joyous art, and a kind of high-level play. If this attitude seems preposterous or vaguely embarrassing to you, stop and think; ask yourself what you've forgotten. Why do you design software instead of doing something else to make money or pass the time? You must have thought software was worthy of your passions once. . .
To do the Unix philosophy right, you need to have (or recover) that attitude. You need to care. You need to play. You need to be willing to explore.
"
Id be surprised if they did.
Nick
Electronic Music Made Using Linux http://soundcloud.com/polyp
And through Windows NT, you can see it throughout the design. In a weak sense, it is a form of Unix. There are so many of the design decisions that have been influenced by that environment. And that's no accident. I mean, we knew that Unix operability would be very important and we knew that the largest body of programmers that we'd want to draw on in building Windows NT applications would certainly come from the Unix base./ industry&tech/uexpo.asphttp://www.microsoft.com/bi llgates/speeches/industry&tech/uexpo.asp>
--Unix Expo Remarks by Bill Gates October 9, 1996 ahref=http://www.microsoft.com/billgates/speeches
Can someone point me towards the developed specifications for XP, etc?
I'm looking for the guidelines as to what should be put in the user profile vs program files, proper registry format, etc. I'd like to print out a foot thick copy and smack people with it whenever they bring in software that requires Administrator access to run.
(Hint to anyone about to fire up the flamethrower: go read up on NTFS or Novell native permissions models. Then have a nice steaming hot cup of clue :)
they could get BSD, and put a GUI on it.
The Kruger Dunning explains most post on
Unix permissions _do suck, they're too simplistic and ACLs solve a lot of the problems inherent to it.
The UNIX® permissions model has had access control lists pretty much forever. Every user can belong to one or more lists of users called "groups", and each file designates a set of permissions ("Access Control") for a group ("List"). Some file systems allow for more sophisticated ACL behavior by specifying more than (access control, group) tuple.
But ACLs are broken anyway; the next wave of permissions architecture is capabilities, as seen in EROS and other research operating systems.
The only way I could see this working (and it may seem excessive) is to by default remove the log in privilege when making an account an administrator. The hope being that people smart enough to give themselves back the permission will use the account responsibly when logged in, and the not-so-smart people will need to live with typing in the admin user and password every time they need to use the privileges. Hopefully the amount of complaining this would cause will provide the necessary impetus for vendors to write decent programs. But M$ likely won't be that mean.
We usually run Linux at our house, but our daughter was given a couple of Windows games. Like a lot of software that dates back to Windows 98 days, they only run under XP if the account has administrator privilege. So, since the only reason the Windows system is there is to let her play the game, and I don't care if she screws it up, she's an admin. It's the same at a lot of other people's houses; everyone is an admin because otherwise their older software doesn't run, and they have no other reason to buy newer programs.
Ffs, parent (and I guess grandparent) are among the VERY VERY FEW posts so far that come from people who know what they are talking about. I could care less what apps require admin rights to install, but seeing parent still at 1 while the 'haha lol i would still not trust m$ security' posts are modded up is just freakin' tragic.
The NT security model is more sophisticated than that of Unix, even with POSIX ACLs. MS are trying to make their app developers actually pay attention to said model. No change in model.
Whence? Hence. Whither? Thither.
This sounds a lot like Capabilities http://www.cap-lore.com/CapTheory/, though it appears that Microsoft gave it a new name (it's also hard to Google on just 'capabilities' as all you get are marketing fluff sites rather than Capabilities).
I think some of this is already in various UNIX and Linux distributions in the form of NSA SELinux and other similar systems. Applications have a set of operations defined that they can do while restricting or denying access to other operations, which is pretty much the same thing as the manifest that Microsoft describes.
I need to dig deeper into the SELinux that's built into my Fedora Core boxes. I'd imagine that if Microsoft actually puts this into Longhorn, general interest in SELinux will also increase.
UNIX' analogue to ACLs is group membership. The way it's supposed to work is that resources belong to groups or are front-ended by setuid applications that are group-execute. So rather than having "dial-out rights" you're supposed to go into the "dial-out group". Windows ends up doing things the same way... rather than juggle rights on a user level, you tend to assign those to resource groups and put people in them (with 'Administrators' being the default example).
Either way, you end up in the same place....
The,
World would be a more beautiful place if Symbolic links were to find themselves in Longhorn alongside those new permission restraints.
---- Go ahead, mod me down, I'll just post it again and you lose your mod points.
I assume that the certificate an IT department uses to sign code will only need to be trusted within the company network.
The certificate signed by the IT department is called the "deployment manifest", not the "application manifest". As I understand it, the publisher of the program is supposed to create and sign the application manifest using a code signing certificate that can be traced back to a Microsoft-approved root CA. The deployment manifest overrides the application manifest, but that's of little use on the desktop if Windows Longhorn Home Edition cannot use deployment manifests.
Windows Server is shipped with a certification authority software
You appear to miss the point. I specifically conjectured that Windows Longhorn Home Edition (not Server) would not be shipped with code signing certificate authority software. If users cannot create and sign deployment manifests, and Microsoft sets up the affordable version of Windows to reject by default any application manifests that are not signed or whose signature is not verifiable to a Microsoft-approved root CA, then an application without a "trusted" application manifest simply cannot be installed. How would a free software developer provide an installable package in this case?
Now if only M$ would fully support soft links, Windoze might even be useable.
Mount points have been supported since 2000 in Windows. And hardlinks. ACLs and multiple streams per file were supported almost from the very beginning.
Before bashing something you should at least RTFM, otherwise you just look like a typical teenage Linux zealot.
Really? What have they stole from Microsoft that Microsoft invented?? Just about everything Microsoft has done was done first by another company which they either bought out or out marketed.
:)
And the sad fact is that it was usually done better before Microsoft put their grubby hands on it. The only thing Microsoft has been innovative on is good marketing... and Open Source is already kicking their ass at that as well.
This is my sig. There are many like it but this one is mine.
Anyone can sign thier manifes (assembly), but if its not from a trusted source, you get a warning saying the cert could not be verified.
You're thinking of what happens when the action for "Install unsigned software" is set to "Prompt". The worry is that Microsoft will set it out of the box to "Disable" rather than "Prompt".
It's not a bad idea to use vmware or Virtual PC to handle unsafe things, like the pos software or web browsing.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Those who don't understand UNIX are doomed to reimplement it. Poorly.
It's not clear to me why the average home user wants to be told by the OS of *his* computer that he can't do the things that he wants to do. Limited user accounts make sense on multiuser systems (where users *don't* own the system and so shouldn't be allowed to damage either it, or each other). They don't make sense when someone's the sole user and owner of a machine. If I want to install Bonzai Buddy or check out the latest e-mail offering nekkid pictures of Anna Kournikova, nothing in the OS should hinder me.
I remember reading this as a joke somewhere (most probably on Slashdot), but basically MS is slowly their own *nix.
.NET scripting - programmable shell like bash, or bash with perl/python/etc.
DOS - Boot Loader
DOS - Also the Shell, probably perfected in Win2k and up
Windows 3.11 - Window Manager. Perfected maybe around Win98SE?
Command Prompt w/
So now it's *nix like permissions. I wonder what's next? I hope it's loadable modules. I hate having to reboot just to remove or install a driver.
Your suggestion shows a complete lack of understanding of the Windows programming model. Windows doesn't use a single filesystem root, so the concept of "chroot" doesn't apply.
Windows already has seperate registry and file areas for system-wide and per-user data. In the registry there are seperate keys for system and user configuration. There's also seperate "All Users" and individual user local settings directories in the Documents&Settings area. Software simply needs to check permissions and use the appropriate areas:
- If the user doesn't have administrative privileges, install registry entries and settings only in the per-user areas. Software will only be usable by the user that installed it.
- If the user has admin privs (or if the installer is run with admin privs), ask the user whether they want to install for all users or only themselves. If they want to install for all users, put system-wide settings into the system-wide areas. The application should create appropriate per-user settings based on the system-wide settings the first time it's run by a user.
- If the app absolutely must be system-wide (eg. part of it's a driver, or it's a program that has to start at start-up before any user's logged in), then either the user needs admin privileges or the installer needs to run with admin privileges. Only the minimum should be installed system-wide, this shouldn't be used as a loophole to continue the current bad practices.
This is pretty much the model Unix follows for software installation.Cheap shot: if Microsoft is such a great, innovative company, why's it taken them 20 years to catch up to 30-year-old software in this area? :)
This was why I had to drop Winamp. My choices were to either run Winamp as Administrator or not have access to the media library function.
Blah. It's a good thing iTunes rocks.
when with almost every major release of a companies operating system, they completely redo the permissions system?
Windows needs the ability to submit jobs fro the forground to the background, and nohup and all that other good stuff.
This is the worst spelling mistake I've seen here for quite some time!
You've managed to write "years" instead of "decades"!
Shame on you...
It may be debated about if this will really help the common user or not, but I think the one thing it will most certainly do is help systems administration by miles -- in such situation where you can, for the most part, manufacture a proper and safe environment for the user to work in. It is also amusing to note how M$ would really like to convince people that their implementation of such concepts as user permissions, or even being a multi-user OS, serve the same purpose as UNIX flavors. Over the years Windows has gone from no user permissions, to some, to more, to their recent scheme with windows 2003 server and the many authentication processes through their exchange server. Any such notion that Windows is a multi-user OS are equally as absurd. This process of making windows a full-fledge enterprise-grade server / client environtment will not be fully realized until the drop the worthless Win32 platform and develop, at the very least, their own *NIX flavor.
It is cmod 777 -R *
1337 15 2
I predict this will be the foundation of so many Ring 0 virii and worms that we'll be laughing about Longhorn for years. Or at least till the end of the decade.
-- Tigger warning: This post may contain tiggers! --
Under windows they will be Luser Permissions.
Adding a meaningful permissions scheme will either kill many of my kids games, force a repurchase, or give me loads of headaches. When we got an XP box, I thought "Great, no crap installed by teenagers." Then I found that none of their games would play without write ability to the game directory in 'Program Files'. So guess what? They are administrators, too. We're not talking small stuff or fly-by-night companies. My kids have worked very hard to keep EA Games in business. I'm glad they will be out of my house when Longhorn comes around. Let the university's tech support sort it out with them.
There were similar problems with Eudora which my wife uses for email. So, she's an admistrator, too. And Eudora had its own headache under XP--she and I could not share mailboxes as we had done under Win98, even if the mailboxes were in a shared directory.
Good thing I have my own Linux box. When the kids and their games leave, I'm getting the Mrs. a Mac and shinning on we're-all-administrators-here Windows for good.
"Love is a familiar; Love is a devil: there is no evil angel but Love." --William Shakespeare ('Love's Labors Lost')
Microsoft's "LUA" is a good idea, but it's 10 years too late. As others have already pointed out, there are *LOTS* of programs that won't run properly -- or won't run at all -- without administrator priviledges. This is blatant stupidity on the part of the programmers who wrote these programs, and has been allowed to go on for so long that it's probably too late to change.
Think about it -- a person buys Longhorn, which automatically logs them on as a low priviledge user, and *BAM* most of their existing programs don't work. So their choices are:
Buy all new software
Log on as administrator
Which do you think people will do? How much grief will Microsoft get from users who discover that Longhorn breaks most of their software?
I can see it now, Microsoft patents user permissions.
There are 10 kinds of people in the world - those who understand binary and those who don't
The security attributes of CAS serve an entirely different purpose. While the principles of least privelege apply to both, CAS allows .NET apps to be run in a sandbox in the same manner as Java applets.
In contrast, the LUA initiative addresses designing and implementing software such that end user privelege requirements are seperated from administrative privelege requirements. This impacts two main concerns. Enterprise admins can deploy and configure software without having to grant users dangerous additional priveleges. And home users can safely run as a normal user and only be prompted for admin credentials when installing software, hardware, or significantly altering the system in some way.
This is a good thing for many reasons. For example, if a home user is browsing with an account that does not have the rights to alter the system, most malware cannot install and removal is much simpler. For businesses, many commercial apps currently require at least power user privelege, and a moderate script kiddy can escalate from power user to admin quite easily which is a dangerous foothold in an enterprise network.
One of the inventors is named Gang Wang.
I love bashing Micro$oft as much as the next person on /., but you have to admit it, this will be transistional piece of the software. Ofcourse, they are not going to just say, let's do this now and we don't care how it affects the end users. Otherwise no one would want to buy Longhorn. That would be extremely stupid and almost suicidal and let's face it, MS may be suicidal, but not stupid,
why was the parent marked troll???? those are some valid points! windows permissiosn arent that transparent or helpful.
Marques Johansson
On OS/2, each program include shared libraries were installed in seperate program directories. This way, one program could overwrite a common directory and break the said program. I also recall how much this "Program Files" where all files are installed in one location was touted and OS/2 was clumsy and so on and so forth. Oh how they are having to eat their own words.
Lots of companies don't provide signed drivers at all for your hardware (perhaps they don't want to fork out the money for testing to microsoft and have to pass the bill on to you).
And most people (including I) really don't care what microsoft thinks about the drivers. If you trust the hardware maker that's sufficient imho. Besides, if you have the hardware, you'll have to use the drivers to get it working - signed or not...
Funny thing is, the signed WHQL drivers off microsoft update screwed up my Toshiba laptop display bad 2 weeks ago. The only drivers that I got working (tried over 12) were non-signed ones straight from Toshiba's website...
I wonder why you even want them to be signed? You don't trust your hardware maker to make drivers without spyware in them or ?? It's more annoying than anything imho.
This is a common misconception, however Deep Freeze thaws quite easily if you attack it directly; it's a limitation of the approach. This is because you cannot protect a system when the protection mechanisms operate at the same privelege as the malicious user. Ask any decent systems programmer or computer security specialist, they'll tell you it's a fact.
In the end Deep Freeze is an artful system of obfuscation involving file system filters and call hooking. It's nicely polished and easy to use, but as with all obfuscation methods it provides no hard protection so you can simply insert your own code and disable the protection directly. This of course does not apply if you log into a "frozen" system as a non-admin user. In that case the OS protections should perform their function, but that really defeats the point now, doesn't it.
The only way to reliably create such a "frozen" system is through emulation or virtualization (such as VMWare). Unfortunately both methods have a fairly high overhead as other posters have complained. And in case you are curious, yes I have cracked Deep Freeze and several similar products, but due to terms of my employment at that time I cannot share the research.
... as I switched away from Micromoron Winblows five years ago.
installing applications can/does put all kinds of stuff directly into the windows system directory.
Perhaps he uses windows instead of just spouting off random BS rebuttals to sound statements.
That's what /etc/fstab is for, specifically the user flag.
Most distros use the owner flag instead and set ownership of the device in a script when logging on from the console. There is no good reason to allow someone who isn't actually sitting at the console to mount or unmount removeable media, and plenty of reasons not to.
As far as installing as a regular user, you are absolutely right, as long as the program doesn't want to use ports under 1024.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Allow me to be the (n)th to say....
"Winix"
Kind of has a ring to it...
I see M$ adopting unix features as really bad news.
Security features like this are enough to make PHB's everywhere believe Longhorn "just as secure" as Linux. The details are too technical for most of them to care.
Add overwhelming amounts of graphic eye-candy and the year of Linux on the desktop is over. Again!
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
You're right. Preventing admins to run something is not a good idea at all. It won't replace user education (for home users running as admins). The only thing it would do is prevent me from doing anything productive at work, being part of many admin groups and what not. I'd require more user accounts, and I'd have to log in and out depending on which apps require to be admin or won't run without being admin, and those that wouldn't run because I'm admin... This is completely stupid.
The problem here is HOME users. Perhaps something could be done in a windows HOME edition ONLY. Like force the creation of non-admin user accounts or such. And even them people will give themselves admin rights back as too much stuff won't run anyways...
The traditional Unix security model is such a disaster that most old Unix hands can't even see it. The best way to prevent anyone from breaking root is to not have root. Oh, and what is up with this "must be root to bind ports 1024" thing in Unix? We complain about it taking MS months to fix vulnerabilities, but that one has been around for decades and it still hasn't been patched.
Shouldn't Microsoft Logo certification do something about this? I mean, isn't there a clause saying "Thou shalt let users run thy program withoust being administratorths" or something?
It already does, and has since Windows 2000. Go read it sometime; this stuff is clearly laid out in section 3.
Now we know why SCOXE needed all the IBM AIX code ..
On the minus side we can now fork bomb Windows!
I am the unwilling control for my Origin.
The most astonishing I have found Rise of Rome. A Microsoft game.
Installations are a pain point for LUA in Windows, because they require files to be written to different areas of the Windows file system and configuration changes in the Windows Registry that often are inaccessible to ordinary user accounts.
This isn't a problem if the installer is at all reasonable: the installer should be a privileged program that performs the installation based on a declarative file that ships with the software package. No package code ever needs to run as root in most cases (and, no, not all Linux package formats get this right either).
Coming from Unix, you're used to asking 'Does this run under root or not?' But Windows operators have never had to consider that. LUA will force that choice on people," he said.
As usual, Microsoft is about 20-30 years behind the state of the art, and about 5 years behind Apple.
To encourage adoption of LUA features and principles, Microsoft has been working closely with Macrovision
Macrovision??? Sounds like the insane are running the asylum.
A scene from 1960:
Bob: I have an idea... Let's make it so that each file will have drwxrwxrwx bits to make it so that each user can control who has access to his files.
The above is carried out and UNIX users benefit for 45 years.
And then a scene from 2005:
Bill: Oh, I know... Let's copy what UNIX has had for years and then tell the world how innovative we are by inventing this great feature that others have already had for generations before us. And let's see if we can patent it while we're at it: Method and apparatus for protecting the identity and data of users in a file system stored in a computer system.
Yeah... That's Microsoft. Where did you want to go yesterday?
It seems to me that the most important thing (on a single user desktop) isn't really the file ownership, but whether it can be executed. Most viruses etc would be killed at a stroke if files were not executable by default. (As for admin vs user, on a single-owner desktop machine, it doesn't really matter as much - after all, the user's private files are far more valuable the the OS.)
The problem is Windows doesn't integrate with them well and MS takes the hands-off approach. I.e., The search all files option, two drives, C: and D: with C:\documentsandsettings\user linked to d:\bigdrive\user - search finds both.
Gods only know which programs remove one and affect the other and most progs aren't link aware...
You are wrong. An admin should be smart enough to not run programs like Word as root/administrator, so it won't matter at all that Word cannot run as administrator. When people start feeling pain because MS packages refuse to run as administrator, while other things require it, they will start demanding other packages not require administrator. As the applications change to allow running as a restricted user, Windows will start to see less security issues because users don't have as much power to make mistakes.
So long as MS allows you to do stupid things like run Word while you have administrator rights, people will do stupid things like run Word with administrator rights.
Oh, and if you really do need to run Word while logged in as administrator, there is always run-as. I don't believe you need that ability though. Its just that there is so much badly written software out there that does require administrator that you don't bother trying to run as non-administrator. I understand, just like everyone else I do the same: run Windows as administrator 100% of the time. (I make sure my personal systems are FreeBSD though where I don't have that pain)
Or they could use a file system where you can rename a file that is in use. Unix had this in 1970. But apparently Microsoft has not gotten around to "innovating" it yet, so to you such an idea just does not exist.
As for your first point, it's quite certain Microsoft is planning an Apple-style system (which is built atop the Unix system, you know). Installing a program will pop up a box that says "you have to type your password in to install this". There won't be any need to log out and then back in as administrator to do things, that would be stupid. Unix would probably have done this years ago except it was easy to log in to root from an existing terminal without having to kill all your programs.
"Light-years ahead of anything Linux is offering" is only true if you're entirely ignorant of any security work done on linux. SELinux and grsecurity both offer features that NT entirely lacks.
And, as a response to my former post explained, "*incredibly* fine-grained" is also untrue. It's only fine-grained in comparison to UNIX permissions bits.
The Unix problem was a large number of programs that were setuid, meaning they got root permissions no matter who ran it. This meant any bugs in them could be exploited to do things with root permissions as well.
Certainly not a good thing, as people have learned, and a lot of those programs were setuid for the same stupid reasons that Windows programs force everybody to run as root, such as the need to write to one status file that the programmer put in a location that is normally root-only, not because they needed special privledges to get their job done.
But this is still far better than Windows. Unless you were root you could not turn any random program into a setuid program. In Windows you are root all the time and thus *all* programs are setuid even if the programmer knows it is not necessary.
I know I'm going to get flamed horribly for this, But I consider this a downgrade. The Windows permission system (which is essentially the VMS permission system) is far better than the one for Unix offering much better controls especially for large scale servers where administrative responsibilities are divided between teams. I think the real problem with Windows is that it didn't go far enough in implementing the VMS permissions model. On VMS its common for highly privileged users to run in an unprivileged state with few privileges except the power to grant themselves most privileges and then do the following:
a) Run in an unprivileged state until they get a privilege error
b) Determine if they really want to do the thing that caused the error
c) If yes temporarily grant themselves permission to do this thing. This is sort of like sudo but only grants one particular type of privilege not everything at once
d) Try again. If they get another permissions error on another permission repeat steps b and c.
e) Once successful (or they decide not to complete the action) then lower their permissions back down to their normal level.
The closest analogy for people haven't used VMS or a mainframe would be OSX when it asks you specifically before you do an administrative task.
This is way safer than Unix's system of permissions. The problem is that applications just fail for lack of privilege and the interface doesn't make it easy to bump all over the place. Frankly I think adopting the Unix model with less fine grained privileges is a major downgrade to NT. The problem is with the applications (including those written by Microsoft) not the OS.
Create a Windows graphical interface for BSD, just like Apple did with OSX. It will be a hell of a lot faster than trying to reinvent the wheel with Longshot.
--
What? The land of the free? Whoever told you that is your enemy.
Tons of software from MS & others on Windows won't work correctly unless user is admin
cough! cough! Oracle 10g , both server and client cough! cough!
Actually you can install and run them as another user, but is fraught with problems unless your user is explcitly a member in the local administrators group.
developers skirted the BIOS because BIOS calls were too slow -- that was back when the BIOS was part of the OS. This is not a Microsoft problem
... as if this memory mapped display was a 300 baud terminal!
It bloody well is a Microsoft problem. They had the ability to improve the performance of the BIOS, ANSI.SYS was frequently ten to a hundred times faster than the BIOS on a typical computer... all they needed to do was intercept the BIOS calls and perform the same operations they did with ANSI.SYS and they would immediately remove any need for people to go around them.
But they didn't. So your choice was ANSI.SYS, or direct hardware access. I went with the BIOS for my terminal program and half my code was "curses" style optimizations to avoid making extra trips into the BIOS
Similarly, the current mess with applications needing to write to %SYSTEMROOT% to install is Microsoft's fault, because for many years they recommended that applications do that... as near as I can tell so they could ship DLL updates through application vendors instead of coming up with their own update mechanism. The result of that? Administrator-level installers, DLL Hell, and viruses being REINSTALLED back into %SYSTEMROOT% by the system restore tools they created to try and work around the problems...
Not Microsoft's fault? Like hell it's not!
While I fully believe that Microsoft needs to take their fair share of the blame on this the lion's share of the blame could well go to lazy programmers. I've given up counting the number of applications I've run across that require that the user have elevated rights. And it is clear that it's not the fault of the OS but rather the application programmer. Given the current state of Windows XP, there's no reason that a user needs to have elevated rights to run a program. Now, installation is another question.
Can I mod the article title -1 Troll, please.
Are there any exploits in the wild that detect and get around Deep Freeze? If not then it is probably a better solution than most. (Sort of like Windows File Protection... )
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
There is no defense of DOS and Windows drive letters. They are terrible. The registry is littered with them, making it impossible to move anything around easily, and they are an awkward and inefficient way of dividing storage.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
The other night my sister was trying to open a link in her Yahoo mail, but was unable to.
The reason was the link led to a PDF file. I had just updated Adobe Reader from 6.0.x to 7 and that involved agreeing to a new EULA on first launch. But I hadn't done that. She couldn't click Agree because she was on an non-admin account (the EULA screen just ignores the click). She had to force quit Firefox to regain control of the machine. Also, there was a Windows Journal Viewer Insatller that gets triggered automatically by Adobe Reader. You have to be in an admin account to install it and the only way to bypass it is to click cancel on the installer over and over again (like a 12-20 times, literally, it launches again and again). This installer has been a thorn in the side of me and my coworkers on the work LAN for awhile.
To fix my sister's problem. I had to log in (I'm admin), open her email and try to open the link so I could agree to the new EULA, and maybe the Journal Viewer finished too in the background, I couldn't tell. Then she could open PDF links normally.
With silliness like this is it any wonder everyone runs their user accounts as admin?
The root (no 'pun' intended) cause of the problem is the developers not writing the programs correctly and Microsofts tendency to ensure backwards compatibility.
In an enterprise environment it is not uncommon to be running ancient Win3x software that has been band-aided to run on XP. There are a lot of things that need Admin rights to install and a few that need it to run.
We've been able to get around the admin rights thing by using SMS server and writing advanced wrappers for the installer packages. But this is not easy and smaller shops will have problems.
On another forum I noted the howls of indignation and protest when Mac users who were used to the old System software took the leap to OS X with Unix permissions and accesses.
A number of us did our best to try to dissuade users from operating in "root" or god mode because it is dangerous. I recall being flamed for having tried to tell one poor soul about how he had regularly and routinely messed up his system by doing that and that if he decided to simply create a user who could administrate the computer, he'd be fine.
"I realize you want the operating system to 'be good' and work that way, but it doesn't. Sorry about that."
And now Microsoft is going to adopt Unix permissions. How wonderful. Apple has a pretty smaller user-installed base. I believe it's growing due to their hardware, like the iPod and their new Mac Mini but it took some patience from Apple gurus as well as Apple to help people over that "permissions things" hump.
Compared to that little dustup, Microsoft's adoption of Unix permissions should be a lot like dropping a 20 gigaton thermonuclear device on the computing world. Apple released a "Repair Permissions" script which should be run regularly after updates to verify and change back any mangled permissions. I'd imagine Microsoft will do the same -- in about three years
Gods don't kill people, people with gods kill people.
"Those who fail to understand Unix are forced to reimplement it. Poorly." Henry Spencer.
What part of "gestalt" don't you understand?
Yeah. I mean, the whole "everything's a file" concept is so hard. Things like being able to assign ownership to your (p)tty. Cuts root right out of the picture.
What part of "gestalt" don't you understand?
And su -c 'command' nobody fails you how? 'sux' for X access, or learn to use xauth properly.
Other than single-user maintenance mode, you should be logged on full root anyway -- log on as user, sudo to root for actions, or run a root shell if necessary. No need to be blatantly stupid.
Given possible exploits in such things as, say, man, an alias or shell function wrapper to do this automatically, as root, might not be all bad.
What part of "gestalt" don't you understand?
What drives me batshit crazy is the fact that the only way to get a copy of a typical legacy MS Windows error message is to screenshot it. Even GNOME managed to allow a copy buffer for its dialogs. Makes the task of either getting valid user reports, or Googleable text, so much easier. CLI of course is even better in this regard.
The combination of 1) content-free error messages and 2) no ready means to copy text means tracking stuff down is orders of magnitude more effed. Thankfully, I don't play there much.
What part of "gestalt" don't you understand?
Not exactly Unix-like. Unix permissions are annoying because you have to choose permissions for one group, for one user (the owner), and then everyone else. So people turn to packages like AFS to expand that. Windows, however, gives you a ton more control built in. Not just more permissions, but the ability to choose a more diverse set of users who have the permissions.
... except better.
:-)
So yeah, Unix-like
Flame me if you like
Not for the 372 users in our facility.
----- You know you have ego issues when you register a domain in your name.
YEAH!
Seriously, it's about time, dangit.
They search.msn.com
(Any predictions as to how soon the top search result will be changed to an MS page instead of lua.org? MS certainly doesn't want people to know there are programming languages other than Visual Basic)
The problem with ACLs? N^2 complexity. The more files you have the more ACLs the more complex it all gets, the more complex a system the less reliable it becomes. Unless you use them properly of course (Nobody does in real life).
The one killer feature I'd love Unix permissions to have from an ACL type permission system is groups within groups. It'd remove the linear increase in admin effort. Other than that Unix permissions are just about right in terms of security and ease of use.
Government of the people, by corporate executives, for corporate profits.
(Most) Unix systems have had ACLs available for a *long* time. They tend not to be used because frankly they are a *pain in the arse* to administer. The effort required to administer ACLs on a set of files exponentially increases with the numbers of files and numbers of ACLs... Unless... You manage them in a Unix permission manner. And if you're going to do that then you might as well just use unix perms.
I would like groups within groups though.
Government of the people, by corporate executives, for corporate profits.
LUA has been there all the time. You Unix-M*ther*f*ckers still tend to ignore this.
Go and f*ck y*urself.
OS X Tiger has a very simple way of doing this - even though they consider it more for kids not grandmothers:
http://www.apple.com/macosx/tiger/parental.html
Scroll down to "Your own personal post office"...
Whats the difference in saying file X can be accessed by groups x, y and z, versus X can be access by x, which y is a member of, and z, which is a memeber of y.
Seems like the latter would be even less clear and more complex to figure out (why does so and so have permissions??).
What if you want to move an application across drives to redistribute free space? What if you run out of letters in the alphabet?
Hmm, I have a take on this:
You can lead a full-bladder horse to an electric fence; how long before it pisses on it?
David Syes
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Don't post these ideas to ms encarta... they'll lay claim to them, try to patent them, and then enjoin you from using your ideas elsewhere... And, if they can't patent-infringement you out of the running, they'll keep lawyer-bombing you until you give up...
(takes off extra layers of tin foil hat (leaving on about two thick layers...)...)
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
The solution is something that will run games as another user. Enter NeoExec. Works great for games (personal use) - commercial licensing may be another matter. Google is your friend.
:)
MSFT did take core design features from VMS, but
threw out all the security capabilities of VMS
for the sake of "usability". The only threats
that I have ever been aware of in the VMS environment
has been when DECNet (NetBIOS) has been used without
restrictive router tables and use of firewalls.
MSFT's adoption of UNIX-like permissions will not
make Longhorn more secure, in and of itself. That
is why MSFT is now counting on hardware-based DRM
(aka Palladium) for their OS security. For MSFT,
"ease of use" has always been more important than
security, which is why we are in the situation we
find ourselves in today. MSFT does own the bulk
of the market share, built upon "usability" -- but
that "usability" extends to the script-kiddies,
trojan, worm, and virus writers that may be 12K
miles away.
The $64 USD question is this: "Will MSFT's newest
attempt at locking down their OS (Longhorn) by way
of hardware-based DRM be considered a security
tipping point for widespread adoption, when compared
to the increasing restrictions placed upon the
users?"
The increasing market share of Mac OS X, as well
as the other BSDs and GNU/linux, would seem to
indicate that MSFT's bumbling "Keystone Kops"
security efforts have not been well received in
the market place.
...that the old legend really *is* true - MS has, on an off-network computer surrounded by Faraday cages, secured by DNA-scan login and 4096-bit-encryption, stored in a bombproof chrome-vanadium steel vault located in the middle of a heavily guarded bunker somewhere deep under the Cascades:
..and of course:
One (1) copy of a program the sole function of which is to compile Windows from the True Source Code. The only user input: checkboxes. For each new version of Windows, one more box becomes unchecked.
This time, they'll uncheck "Disallow non-administrator accounts normal security permissions needed to install common software," possibly also "Generate random hardware driver malfunctions and system hangs" - no, the latter they'll slowly phase in as Linux gains in compatibility with newer hardware.
Remaining in the default compilation for Longhorn:
+ Create enormous fragmented swapfiles
+ Refuse to allow user interaction by mouse, keyboard, or other input devices intermittently
(with "display hourglass cursor, blink irregularly to give impression of computer hard at work" enabled)
+ Generate random cache misses and hard disk activity
+ Grow registry at each logon
+ Generate random HKEY_CLASSES_ROOT and HKLM\SYSTEM\ControlSet\* registry keys and values
+ Progress bar friction [the feature that enables progress bars for installations, driver DB searches, etc to move steadily to the 90% mark, then hang for minutes at a time - and in the case of copying files with Explorer, sometimes even move backwards]
+ Error message obfuscator
+ DLL memory space destabilizer
+ Microsoft encryption escrow link (use all default-enabled TCP ports in invisible mode)
+ Corrupt NTFS indexes and security descriptors during file writes
+ Mandatory 30-60 second Shutdown waitstate
+ Steal, lock GDI, User stack memory space over time
+ Intermittent kernel fault: on
+ Insert CPU waitstates into third-party browser executable code
+ Random power cycling during Windows startup
+ Intermittent DRIVER_IRQL_NOT_LESS_OR_EQUAL during boot: reset counter each time PCI or memory cards reseated
+ Remove pertinent Help topics and index words on-the-fly (redirect to Microsoft "Premium Support" webpage)
+ Pop up Wizard character over cursor at whim
To name a few.
Thus, the original Windows Perfect Edition (a subtly copyright-noninfringingly-rewritten version of BSD Unix) will be slowly unveiled over the next ten to twenty years.
actually the GNOME session management is great. you can have the gnome web browser epiphany and say some gnotepad (whatever its called) open with multiple tabs and just logout ... and when you log backin the apps return... (get this) in their previous state... really simple and functional idea..
Correctly installed, a user should not even have execute permission on his home directory. I can't think of any reason why an ordinary user should be able to download and execute anything. Our machines are configured with read/write/search ACL on the default home directories (My Documents, and the hidden ones); Only programs has execute permissions and desktop users can write in that directory. But I agree, there are some ill-formed programs that require too many privs to run.
You know that Microsoft is going to patent this, so we shouldn't get all excited about it when they do, even though it's existed since the beginning of time.
Patent it first, and license it free.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
How many of you have said, "The only way Longhorn will even approach a useable OS is if it uses Unix-style permissions and doesn't require the user to run as Administrator to get work done"? I know I have. And I've been a Windows admin longer.
Seems they might actually have people htinking about problems and solving them.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers