Okay, I realize that cooperation with Microsoft may be useful, but this is a little nervousness-inducing:
Spokesman Frank Federau for the Lower Saxony police said the man was arrested Friday. Federau said the suspect admitted to programming the worm, but authorities did not know if he had created all the versions of it.
"He made a confession, and the experts at Microsoft have now confirmed that he was the cause of this worm," Federau said. He said he did not have any details of how the suspect was found.
So...while I realize that this is a black eye for Microsoft, and that it's to their benefit to assist in tracking the guy down, and I realize that police budgets may not allow for competent cybercrime investigators, it always makes me nervous to see police saying "investigators from <large global corporation> have confirmed that this guy is the culprit". Yes, he'll have his day in court, but still...damn.
Not a concern. Apple will never take the personal computing market -- they chose the "lucrative but closed platform" approach that Sun did, where you have to buy Apple hardware to use Apple software. The market won't move from vendors that provide competition (and better prices) to a single, closed platform en masse. It just isn't going to happen -- most Microsoft-centric complaints today are simply because Microsoft had a software monopoly. Businesses are not going to be burned again. This isn't a slam at Apple -- what they did seems to have done reasonably well for them -- but it does mean that they don't compete directly against Microsoft for the masses of businesses out there.
Apple gaining market share is good for almost everyone (the sole exception would be Microsoft shareholders). Apple (and I'm not saying that this is by preference, but by necessity from not being a monopoly in the PC industry) has, along with the rest of the OS folks, gone with UNIX. They weaken the effectiveness of Microsoft programs to produce lock-in. They help weaken arguments for homogenous computing environments being a phenomenal idea. I use Linux, but I don't care if people want to use BeOS, Mac OS X, or FreeBSD. It makes them happy, and I'm all in favor of that. The only reason a lot of Linux folks get irritated about what the masses use is that they get indirectly impacted by Microsoft pushes to cause lock-in -- closed protocols (like Windows filesharing), closed formats (like Office's) and deliberate attempts to avoid intercompatibility. Any market share Apple gains weakens attacks Microsoft does on Linux, which is great for those of us who are fed up with dealing with Windows.
Even better, a lot of FOSS software that I work on also works under Mac OS X, and Mac OS X FOSS work (if to the POSIX APIs) works on Linux, so there's a lot of shared effort. Plus, Mac OS X users run software on PowerPC, which is a great way to test and turn up nasty C mistakes.
Suggested software to avoid being an advertisement-reading whore:
* Firefox. FOSS. Good at blocking popups. Can accept cookies only from the website issuing a page (good for thwarting DoubleClick and friends). Can allow only session cookies.
* Privoxy. FOSS. A superset of much of Firefox's functionality. Allows powerful control over ad-blocking, including blocking based on image size, regexes, allowing only session cookies, can have exclusion regexes, can be disabled per-site or temporarily, tells you why and when it blocks something. Can chain to another proxy. A continuation of Junkbuster. If you use a web browser, you should also use Privoxy -- it's the first worthwhile end-user proxy I know of.
* SpamAssassin. The best there is when it comes to FOSS spam blocking. Supports just about every mechanism under the sun. Unfortunately, a pain in the ass to set up for Windows use -- phenomenal on *IX, though.
* ClamAV. Not really for blocking ads, but the other half of the FOSS SpamAssassin/ClamAV formula for eliminating junk from your inbox.
* GPG. FOSS and a nice piece of software. If you get signed emails from your buddies (and there's no reason for at least *you* not to use GPG if you're using a mail client with good PGP support like Thunderbird or mutt, since it lets you sign your emails and let your buddies ensure that they aren't getting forged emails, besides advertising the fact that they can send encrypted email to you), you can mark something as definitely not spam.
For those who have no idea what is being talked about (for *years* I heard the term "fnord" being referenced and had no idea where people were getting it from), read the Illuminatus Trilogy.
Or don't. I found it to be confusing and bizarre. The authors like to switch between viewpoints of characters without warning (and a few times, in the middle of paragraphs). Some characters have viewpoints that are distorted by being wrong or doped up, one character is a dolphin (and has correspondingly un-human thoughts), the whole mess is added to by the fact that much of the book takes place in flashbacks and that it's very difficult to tell who is insane and who isn't, the fact that much of the content is complex uber-paranoid consipracy theory and religious or philosophical -- oh, and the fact that there are backreferences to all kinds of minor details throughout the books.
It isn't *quite* that bad. I believe that the original Sasser didn't do that much damage. In any event, it was easy to detect, whereas individual compromises could have gone on for a long time. Finally, the way people patched was by running windows Update, which generally yanked down a whole ton of fixes, rather than just one.
The worst-case scenerio would have been either an extremely damaging worm going out or no worm going out and regular manual compromises of such machines.
That doesn't mean that the guy should get credit for doing humanitarian work -- it just means that he may have inadvertently helped people out.
This is not trivial unless you avoid MS software. Really, who would have thought that MS Office secretly embeds unique identifiers in documents until after the Melissa guy was caught?
That could have caused plenty of fun if some whistleblower uncovered, say, nasty financial dealings involving the Feds and Iraq.
If one brags about one's accomplishment (getting into the newspapers all over the world is probably a bit of a pride-inducer for a high school student) on public IRC servers, it's a pretty good bet that law enforcement of various countries knows about you.
In the US, an 18-year-old is a man and not a minor from a legal standpoint. In the US, he would be tried as an adult, with corresponding potential penalties. I'm not sure what other term one could use.
The most common thing I've found to induce audible noise (I use a SB Live, and can easily hear this with even cheap speakers) is to demute the sound card inputs that aren't connected to anything -- like CD audio and whatnot -- and then start moving my PS/2 mouse, which generates a fairly slow sequence of signals, producing a definite buzz. Video redraw also can do this -- dragging windows works well as well, and what's on the screen (oddly enough, lots of white areas seems to cause more of a buzz) has an impact.
It's really amazing how dirty a computer power supply is -- I also picked up a headphone preamp that fits inside a 5.25" drive bay, and can optionally run off the computer power supply. If it's running off the power supply, I get a *very* noisy signal that is affected by things like hard drive access.
I'm pretty sure Microsoft knows what keys it has issued, and which ones haven't. You hit the server with an unissued/unknown key, that's a pretty big sign that you're in the wrong.
* It's a pretty good guess that media vary a lot. So maybe after a five year study, you conclude that the longest-lived disks are a particular variant of Sony-sold discs. It's even odds that Sony isn't making that exact brand of media anymore, and hasn't for years.
* It's really not possible to do very good real-world testing -- you have to do accelerated aging or something, as a seventy-five year test not takes forever, but wouldn't be useful at the terminus. Accelerated aging doesn't model the real world perfectly (if we knew what to do to exactly model the real world, we wouldn't need to do the study in the first place).
There is one good point -- we have no good computer archival media that I know of, and certainly not inexpensive computer archival media.
There are stone carvings made thousands of years ago that are still readable now. It's doubtful that much of today's media will be usable (ignoring the possibility of whether there will even be readers around) in one hundred years. Magnetic tapes demagnetize. CDRs degrade and yellow, CDRW inks alter, hard drives have bearings die and platters demagnetize.
If it was up to me, I'd generate a "hotfix" for pirated copies that wipes the product key info, and pops up that little key icon in the system tray with a balloon saying "You are using a pirated key. Click here to purchase a valid one.", and linking to Microsoft's store. Perhaps a timer is also in order, giving you 30 days(?) to set things right before networking no longer works, or the system won't go past the login screen. That sort of thing.
Uh, huh. Right. How are you going to detect pirated copies again? Maybe look for more than N auth requests per day from different IPs? So the first thing that happens is the next Windows worm running around grabs the registration data from copies of Windows and starts spreading it around. Microsoft detects "pirate" copies, and blacklists the number. People start having Windows-based webservers and the like going down. The entire auth system immediately becomes completely unusable for anyone, since registration data has leaked. Not a good solution.
* I know of no distros that grant a user ownership of part of the hierarchy beneath their home directory. An example of this would make/home/ltorvalds be owned by Mr. Torvalds, but rtorvalds' $HOME be/home/ltorvalds/private.
Why is this important?
Currently, if a user wants to share files with others (or expose files to a webserver or something), it's required for them to make their home directory world-listable (and the lack of standard ACLs means that they cannot even allow "just the webserver" in, which is still a breech of security). (They can then create ~/public_html). This is Very Bad from a security standpoint. Because *IX convention dictates that software shall store local config files under $HOME/.programname, this exposes to the entire world what programs a user runs. It also means that if the user stores any files or directories in their home directory, they are world-visible (I dunno if you like everyone with accounts on the machine being able to view your home directory, but I'm not a fan of the idea). Finally, if you're using a umask with any permission bits set for world (as is default on Red Hat and most Linux distros, presumably to facilitate sharing files that have been placed in public directories), it means that everyone can read your files. This is Very Bad. Some sysadmins work around this by scattering a user's files across the system -- creating/var/www/html/rtorvalds, say -- but then it's a main to administer and add and remove users.
ACLs cannot fix this problem, only reduce the egregiousness of it by reducing the number of people that can be poking around in someone's private area.
A better solution (and obviously one that would cause friction for a bit) would be a reworking of the standard *IX directory layout. Here's my take on it:/home/<username> shall be chmod 751. It shall be owned by the the user and the user's private group, as shall all the directories I mention here unless otherwise noted./home/<username>/private shall be chmod 750. $HOME shall point to this directory./home/<username>/public shall be chmod 751. . Programs that wish to create world-readable directories owned by the user shall default to a directory created in this directory. If the user wishes to create world-readable directories, they shall be created in this directory. A good example of this is public_html./home/<username>/dropbox shall be chmod 3777. This provides an easy mechanism to make files available to other users -- anyone can dump a file in your dropbox. Since this is sgid, not suid, it means that it will not count against uid-checking quotas, and hence cannot be used as a DoS against you.
Default umask shall be 0027, not the current (common on Linux and definitely on RH) of 0022. This makes it a harder to share files (users may hit permission problems by default when dumping things into public_html), and easier to not accidently expose masses of your own files. It's also necessary for the dropbox scheme to work without people accidently sharing masses of files that they didn't intend to.
There are a couple of disadvantages. Users have to chmod o+r files going into the/home/username/public area (at the cost of additional complexity, this can be worked around by creating an everyone group containing all users -- and naturally, having the admin tools add new users to said group -- and making the/home/username/public directory sgid and owned by that group.). There is a bit more typing (though most of what the user is working with is under ~, same as before, so it isn't a huge impact. The user gains (a) a standard way to give files away to other users, which is not present, (b) a standard way to make files publically available. (c) the ability to make files publically available without revealing their private files.
I agree that complexity is one of the primary reasons for security problems. ACLs are the cause of much complexity, but not all.
There are a couple of drawbacks to ACLs (versus the *IX user-owner/group-owner scheme). They hurt performance a bit. They are more difficult to audit. It's easier to miss a permission that shouldn't be present. In general, I'd like to reduce complexity (one way of doing this might be to not actually set any ACLs by default on a vanilla box, and have ls clearly denote files with ACLs attached, so that there are few files to worry about -- I can get a list of all the ACL-using files on such a system very quickly).
The reason I think that ACLs are generally worth the added complexity is that there are a few common tasks (like the one I listed) that are very difficult or impossible to do without allowing unwanted access without using ACLs. Furthermore, ACLs more naturally mirror the way most people think about permissions ("Bob and Mary should have read access" rather than "There is a group of people that own this file, and Bob and Mary are part, and the owning group has only read access").
I recognize that this is an issue. I also think that the Windows security system is absurdly complicated. I don't think that throwing ACLs out entirely is a good solution, though.
Some people use the glob "*NIX" to match Unix and Unix-like OSes. I started using "*IX" to match AIX as well. Naturally, Linus had to use "u" instead of "i", which screws up the system, but yes, when I say "*IX" I mean Unix, Linux, and all such OSes.
I agree that the Linux learning curve is steeper -- however, I also feel that I get things done on Linux much more quickly now that I've got a good chunk of that curve behind me -- I rarely do much repetitive work manually anymore, because everything can be done with a couple of POSIX commands or a perl script. For example, I've seen a lot of Windows users renaming files en masse by hand. Suppose they have a lot of image files that they've downloaded named "conventionPhoto001.jpg", "conventionPhoto002.jpg" that they want to call "AniCon-001.jpg", "AniCon-002.jpg", etc. I'd just type rename conventionPhoto AniCon- *.jpg. I just saved five or ten minutes of repetitive, annoying work.
The biggest gain I can think of would be moving from an initscript system in which all services are serially numered to one where dependencies are expressed with a directed acyclic graph. All you have is "X depends on network being up" "cups depends on network being up", etc.
You could even leave in the old numbers (or *generate* the old-style numbers from the acyclic graph) and do serialized booting if necessary for troubleshooting.
There's no reason not to have as many service starting at once as possible, and several benefits.
* Boot time would decrease because Linux has a good disk scheduler and keeping more outstanding requests keeps the scheduler well-fed with requests to optimize the order of.
* Boot time would decrease because Linux service startups are not constantly hitting the disk. Some hit the network or the CPU. You want to keep a steady stream of requests to the disk running.
* User-percieved boot time would decrease because the first thing that the user generally cares about is the password dialog (and subsequently their desktop). With a DAG, a partial ordering of the boot sequence, the init system has the freedom to load X up as soon as possible and get the user to a password prompt, and continue loading less important things (ntp and the like, sendmail, etc) in the background.
Slashdot Mirror
Okay, I realize that cooperation with Microsoft may be useful, but this is a little nervousness-inducing:
Spokesman Frank Federau for the Lower Saxony police said the man was arrested Friday. Federau said the suspect admitted to programming the worm, but authorities did not know if he had created all the versions of it.
"He made a confession, and the experts at Microsoft have now confirmed that he was the cause of this worm," Federau said. He said he did not have any details of how the suspect was found.
So...while I realize that this is a black eye for Microsoft, and that it's to their benefit to assist in tracking the guy down, and I realize that police budgets may not allow for competent cybercrime investigators, it always makes me nervous to see police saying "investigators from <large global corporation> have confirmed that this guy is the culprit". Yes, he'll have his day in court, but still...damn.
Declining market share is different from declining userbase.
More people using computers means that even if market share shrinks, userbase grows.
Not a concern. Apple will never take the personal computing market -- they chose the "lucrative but closed platform" approach that Sun did, where you have to buy Apple hardware to use Apple software. The market won't move from vendors that provide competition (and better prices) to a single, closed platform en masse. It just isn't going to happen -- most Microsoft-centric complaints today are simply because Microsoft had a software monopoly. Businesses are not going to be burned again. This isn't a slam at Apple -- what they did seems to have done reasonably well for them -- but it does mean that they don't compete directly against Microsoft for the masses of businesses out there.
Apple gaining market share is good for almost everyone (the sole exception would be Microsoft shareholders). Apple (and I'm not saying that this is by preference, but by necessity from not being a monopoly in the PC industry) has, along with the rest of the OS folks, gone with UNIX. They weaken the effectiveness of Microsoft programs to produce lock-in. They help weaken arguments for homogenous computing environments being a phenomenal idea. I use Linux, but I don't care if people want to use BeOS, Mac OS X, or FreeBSD. It makes them happy, and I'm all in favor of that. The only reason a lot of Linux folks get irritated about what the masses use is that they get indirectly impacted by Microsoft pushes to cause lock-in -- closed protocols (like Windows filesharing), closed formats (like Office's) and deliberate attempts to avoid intercompatibility. Any market share Apple gains weakens attacks Microsoft does on Linux, which is great for those of us who are fed up with dealing with Windows.
Even better, a lot of FOSS software that I work on also works under Mac OS X, and Mac OS X FOSS work (if to the POSIX APIs) works on Linux, so there's a lot of shared effort. Plus, Mac OS X users run software on PowerPC, which is a great way to test and turn up nasty C mistakes.
US authorities helped the German police in both cases.
In other news, crackers continue to use unencrypted communication between each other on untrusted IRC servers. Guess what? The Fed isn't stupid.
It's like watching people use cell phones for years to transfer incriminating messages to each other.
Suggested software to avoid being an advertisement-reading whore:
* Firefox. FOSS. Good at blocking popups. Can accept cookies only from the website issuing a page (good for thwarting DoubleClick and friends). Can allow only session cookies.
* Privoxy. FOSS. A superset of much of Firefox's functionality. Allows powerful control over ad-blocking, including blocking based on image size, regexes, allowing only session cookies, can have exclusion regexes, can be disabled per-site or temporarily, tells you why and when it blocks something. Can chain to another proxy. A continuation of Junkbuster. If you use a web browser, you should also use Privoxy -- it's the first worthwhile end-user proxy I know of.
* SpamAssassin. The best there is when it comes to FOSS spam blocking. Supports just about every mechanism under the sun. Unfortunately, a pain in the ass to set up for Windows use -- phenomenal on *IX, though.
* ClamAV. Not really for blocking ads, but the other half of the FOSS SpamAssassin/ClamAV formula for eliminating junk from your inbox.
* GPG. FOSS and a nice piece of software. If you get signed emails from your buddies (and there's no reason for at least *you* not to use GPG if you're using a mail client with good PGP support like Thunderbird or mutt, since it lets you sign your emails and let your buddies ensure that they aren't getting forged emails, besides advertising the fact that they can send encrypted email to you), you can mark something as definitely not spam.
For those who have no idea what is being talked about (for *years* I heard the term "fnord" being referenced and had no idea where people were getting it from), read the Illuminatus Trilogy.
Or don't. I found it to be confusing and bizarre. The authors like to switch between viewpoints of characters without warning (and a few times, in the middle of paragraphs). Some characters have viewpoints that are distorted by being wrong or doped up, one character is a dolphin (and has correspondingly un-human thoughts), the whole mess is added to by the fact that much of the book takes place in flashbacks and that it's very difficult to tell who is insane and who isn't, the fact that much of the content is complex uber-paranoid consipracy theory and religious or philosophical -- oh, and the fact that there are backreferences to all kinds of minor details throughout the books.
It isn't *quite* that bad. I believe that the original Sasser didn't do that much damage. In any event, it was easy to detect, whereas individual compromises could have gone on for a long time. Finally, the way people patched was by running windows Update, which generally yanked down a whole ton of fixes, rather than just one.
The worst-case scenerio would have been either an extremely damaging worm going out or no worm going out and regular manual compromises of such machines.
That doesn't mean that the guy should get credit for doing humanitarian work -- it just means that he may have inadvertently helped people out.
This is not trivial unless you avoid MS software. Really, who would have thought that MS Office secretly embeds unique identifiers in documents until after the Melissa guy was caught?
That could have caused plenty of fun if some whistleblower uncovered, say, nasty financial dealings involving the Feds and Iraq.
If one brags about one's accomplishment (getting into the newspapers all over the world is probably a bit of a pride-inducer for a high school student) on public IRC servers, it's a pretty good bet that law enforcement of various countries knows about you.
In the US, an 18-year-old is a man and not a minor from a legal standpoint. In the US, he would be tried as an adult, with corresponding potential penalties. I'm not sure what other term one could use.
The most common thing I've found to induce audible noise (I use a SB Live, and can easily hear this with even cheap speakers) is to demute the sound card inputs that aren't connected to anything -- like CD audio and whatnot -- and then start moving my PS/2 mouse, which generates a fairly slow sequence of signals, producing a definite buzz. Video redraw also can do this -- dragging windows works well as well, and what's on the screen (oddly enough, lots of white areas seems to cause more of a buzz) has an impact.
It's really amazing how dirty a computer power supply is -- I also picked up a headphone preamp that fits inside a 5.25" drive bay, and can optionally run off the computer power supply. If it's running off the power supply, I get a *very* noisy signal that is affected by things like hard drive access.
Or just use a camera cell phone.
I'm pretty sure Microsoft knows what keys it has issued, and which ones haven't. You hit the server with an unissued/unknown key, that's a pretty big sign that you're in the wrong.
Right. Such a worm would not be affected by this.
Yeah, but there are hard problems:
* It's a pretty good guess that media vary a lot. So maybe after a five year study, you conclude that the longest-lived disks are a particular variant of Sony-sold discs. It's even odds that Sony isn't making that exact brand of media anymore, and hasn't for years.
* It's really not possible to do very good real-world testing -- you have to do accelerated aging or something, as a seventy-five year test not takes forever, but wouldn't be useful at the terminus. Accelerated aging doesn't model the real world perfectly (if we knew what to do to exactly model the real world, we wouldn't need to do the study in the first place).
There is one good point -- we have no good computer archival media that I know of, and certainly not inexpensive computer archival media.
There are stone carvings made thousands of years ago that are still readable now. It's doubtful that much of today's media will be usable (ignoring the possibility of whether there will even be readers around) in one hundred years. Magnetic tapes demagnetize. CDRs degrade and yellow, CDRW inks alter, hard drives have bearings die and platters demagnetize.
That is *absurd*. Not every person that points out that the BSA is full of BS is "legitimizing piracy".
If it was up to me, I'd generate a "hotfix" for pirated copies that wipes the product key info, and pops up that little key icon in the system tray with a balloon saying "You are using a pirated key. Click here to purchase a valid one.", and linking to Microsoft's store. Perhaps a timer is also in order, giving you 30 days(?) to set things right before networking no longer works, or the system won't go past the login screen. That sort of thing.
Uh, huh. Right. How are you going to detect pirated copies again? Maybe look for more than N auth requests per day from different IPs? So the first thing that happens is the next Windows worm running around grabs the registration data from copies of Windows and starts spreading it around. Microsoft detects "pirate" copies, and blacklists the number. People start having Windows-based webservers and the like going down. The entire auth system immediately becomes completely unusable for anyone, since registration data has leaked. Not a good solution.
I have Linux on my machine. I don't even run Windows.
I still get inconvenienced when the masses of Windows-using people out there propagate along the latest worm and bog down the network.
So, at least to me, the question is "do I have to put up with bugginess indirectly caused me by Microsoft software flaws"?
Congratulations - you have proven Godwin's law once again. And, in accordance with long-standing Internet tradition, you have also lost the argument.
Godwin's Law is only used by people that don't have a counterargument.
* I know of no distros that grant a user ownership of part of the hierarchy beneath their home directory. An example of this would make /home/ltorvalds be owned by Mr. Torvalds, but rtorvalds' $HOME be /home/ltorvalds/private.
/var/www/html/rtorvalds, say -- but then it's a main to administer and add and remove users.
/home/<username> shall be chmod 751. It shall be owned by the the user and the user's private group, as shall all the directories I mention here unless otherwise noted. /home/<username>/private shall be chmod 750. $HOME shall point to this directory. /home/<username>/public shall be chmod 751. . Programs that wish to create world-readable directories owned by the user shall default to a directory created in this directory. If the user wishes to create world-readable directories, they shall be created in this directory. A good example of this is public_html. /home/<username>/dropbox shall be chmod 3777. This provides an easy mechanism to make files available to other users -- anyone can dump a file in your dropbox. Since this is sgid, not suid, it means that it will not count against uid-checking quotas, and hence cannot be used as a DoS against you.
/home/username/public area (at the cost of additional complexity, this can be worked around by creating an everyone group containing all users -- and naturally, having the admin tools add new users to said group -- and making the /home/username/public directory sgid and owned by that group.). There is a bit more typing (though most of what the user is working with is under ~, same as before, so it isn't a huge impact. The user gains (a) a standard way to give files away to other users, which is not present, (b) a standard way to make files publically available. (c) the ability to make files publically available without revealing their private files.
Why is this important?
Currently, if a user wants to share files with others (or expose files to a webserver or something), it's required for them to make their home directory world-listable (and the lack of standard ACLs means that they cannot even allow "just the webserver" in, which is still a breech of security). (They can then create ~/public_html). This is Very Bad from a security standpoint. Because *IX convention dictates that software shall store local config files under $HOME/.programname, this exposes to the entire world what programs a user runs. It also means that if the user stores any files or directories in their home directory, they are world-visible (I dunno if you like everyone with accounts on the machine being able to view your home directory, but I'm not a fan of the idea). Finally, if you're using a umask with any permission bits set for world (as is default on Red Hat and most Linux distros, presumably to facilitate sharing files that have been placed in public directories), it means that everyone can read your files. This is Very Bad. Some sysadmins work around this by scattering a user's files across the system -- creating
ACLs cannot fix this problem, only reduce the egregiousness of it by reducing the number of people that can be poking around in someone's private area.
A better solution (and obviously one that would cause friction for a bit) would be a reworking of the standard *IX directory layout. Here's my take on it:
Default umask shall be 0027, not the current (common on Linux and definitely on RH) of 0022. This makes it a harder to share files (users may hit permission problems by default when dumping things into public_html), and easier to not accidently expose masses of your own files. It's also necessary for the dropbox scheme to work without people accidently sharing masses of files that they didn't intend to.
There are a couple of disadvantages. Users have to chmod o+r files going into the
Oh, yes, and (d) by
That should be "suid/sgid directories", not "sticky directories" when I was talking about giving away files.
I agree that complexity is one of the primary reasons for security problems. ACLs are the cause of much complexity, but not all.
There are a couple of drawbacks to ACLs (versus the *IX user-owner/group-owner scheme). They hurt performance a bit. They are more difficult to audit. It's easier to miss a permission that shouldn't be present. In general, I'd like to reduce complexity (one way of doing this might be to not actually set any ACLs by default on a vanilla box, and have ls clearly denote files with ACLs attached, so that there are few files to worry about -- I can get a list of all the ACL-using files on such a system very quickly).
The reason I think that ACLs are generally worth the added complexity is that there are a few common tasks (like the one I listed) that are very difficult or impossible to do without allowing unwanted access without using ACLs. Furthermore, ACLs more naturally mirror the way most people think about permissions ("Bob and Mary should have read access" rather than "There is a group of people that own this file, and Bob and Mary are part, and the owning group has only read access").
I recognize that this is an issue. I also think that the Windows security system is absurdly complicated. I don't think that throwing ACLs out entirely is a good solution, though.
Some people use the glob "*NIX" to match Unix and Unix-like OSes. I started using "*IX" to match AIX as well. Naturally, Linus had to use "u" instead of "i", which screws up the system, but yes, when I say "*IX" I mean Unix, Linux, and all such OSes.
I agree that the Linux learning curve is steeper -- however, I also feel that I get things done on Linux much more quickly now that I've got a good chunk of that curve behind me -- I rarely do much repetitive work manually anymore, because everything can be done with a couple of POSIX commands or a perl script. For example, I've seen a lot of Windows users renaming files en masse by hand. Suppose they have a lot of image files that they've downloaded named "conventionPhoto001.jpg", "conventionPhoto002.jpg" that they want to call "AniCon-001.jpg", "AniCon-002.jpg", etc. I'd just type rename conventionPhoto AniCon- *.jpg. I just saved five or ten minutes of repetitive, annoying work.
The biggest gain I can think of would be moving from an initscript system in which all services are serially numered to one where dependencies are expressed with a directed acyclic graph. All you have is "X depends on network being up" "cups depends on network being up", etc.
You could even leave in the old numbers (or *generate* the old-style numbers from the acyclic graph) and do serialized booting if necessary for troubleshooting.
There's no reason not to have as many service starting at once as possible, and several benefits.
* Boot time would decrease because Linux has a good disk scheduler and keeping more outstanding requests keeps the scheduler well-fed with requests to optimize the order of.
* Boot time would decrease because Linux service startups are not constantly hitting the disk. Some hit the network or the CPU. You want to keep a steady stream of requests to the disk running.
* User-percieved boot time would decrease because the first thing that the user generally cares about is the password dialog (and subsequently their desktop). With a DAG, a partial ordering of the boot sequence, the init system has the freedom to load X up as soon as possible and get the user to a password prompt, and continue loading less important things (ntp and the like, sendmail, etc) in the background.
I'm just curious -- anyone reading this that can beat the listed uptime?