Several people have already mentioned part of this approach, but not combined it.
1) Suspend a steady platform with bungee cords, ropes, whatever. It's far more important for it to be flexible than stretchy. You probably want to attach a few cords on the bottom to stop swinging - these should be stretchy.
2) Add extra mass to this platform - something like a layer of bricks. This will put the suspension cords under more tension (which allows them to transmit more vibrational energy), but the extra mass of the system should decrease the motion seen.
3) On top of this platform, put the partly inflated inner tube mentioned elsewhere. This platform holds the computers.
This is more complex than a single suspension system, but a single system will still transmit some key harmonic frequencies. But it's unlikely that two independent systems will share harmonics so there should be very little energy transmitted into the disks.
I can think of at least two excellent reasons off the top of my head.
First, it's a considerable expense and hassle. Patent attorneys are not optional - the claims have to be properly worded for the USPTO office to accept them *and* to prevent some business from stealing your idea by rewording an ineffectual claim ever so slightly. If you're a business and want to create market entry barriers to your competition, $10-20k might be a good investment. If you're a working stiff, that's a lot harder to justify. If you're still in college, forget it!
Second, by seeking patents for "obvious" things we're implicitly accepting the validity of all other obvious patents. A sadly too common analogy is elections in corrupt regimes - you can organize a voter boycott because the election is corrupt, you can run your own candidate, but you can't do both.
"Freedom of Assembly" has always been held to mean two things. You can have a meeting with like-minded people, and you can eject all others. This protected the NAACP membership list in the 50s and 60s, and the KKK membership list a few years ago.
"Freedom of Religion" means that you can attend the church of your choice - or none at all. At the same time you can refuse to attend any or all churches.
"Freedom of the Press" means that you can print truthful information that embarasses the government. You can also refuse to publish things that the government wants you to publish. <u>High Times</u> Magazine does not have to include a monthly message from the Drug Czar, etc.
"Freedom to Petition for Redress" means that you can ask your Congressional delegates to pass a law, etc. But it doesn't require you to write them about every passing thought you have.
So why do so many people think that "Freedom of Speech," the final element of the First Amendment, means that you have to listen to every idiot standing on a soapbox?! OF COURSE "Freedom of Speech" includes the right to ignore the other person. And not just passively - unwanted guests at assemblies can be forcefully removed by the police and prosecuted for 'trespassing,' so it's not unreasonable to invoke the power of the state to suppress people who just won't accept that their message is unwanted.
A few years ago, spam was tolerated because the social cost of hitting "delete" a couple times each day was less than the cost of fighting it. It was often compared to the effort involved in tossing a couple of pieces of daily junk mail in the trash.
But now many people are seeing three or four times more spam than real messages. It's not unreasonable to expect this ratio to be much worse in the next few years. Imagine finding your snail mail box full of mail, with hundreds of envelopes, each and every day. You have to spend at least an hour, each and every day, looking for your bills, correspondence, etc. Many of the envelopes are intentionally disguised to look like important messages. (E.g., it's a letter from the IRS - announcing an "Inventory Reduction Sale" at the local "Herb Tarlek" Car Lot!")
This won't help Sean, but Patrick should seriously consider running for the school board.
If the administrators won't do their job - ensuring a safe public education for ALL students - then REMOVE THEM FROM OFFICE!. If the principal won't do his job, fire him for cause! (Something that the school board can do).
The principal and school board will drag out this case for years in the court, and will do everything they can to keep others from learning the details. They'll even claim it's for Sean's protection.
But they can't stop the media from covering a candidate for political office demanding accountability by principals when they attempt to violate the Constitutional rights of students. They can't stop the media from doing "candidate profiles" where Patrick explains that he's running the school board because his son was hounded out of the school by teenage morons and spineless administrators -- and he wants to protect other families from the pain his suffered.
As an aside, our local school board got out of control a few years ago. They eventually sacked the popular principal of one of the high schools, installing their own crony. None of them survived the next election cycle, and that ex-principal became the new head of the school board. School board elections are normally low on the political radar - unless you have children in the public schools, they rarely grab your attention. But that means that one person, with a good cause, can bring in enough extra voters to replace boards en masse.
Something many people overlook is that paper isn't damaged, too much, by steam and smoke, but computer media is destroyed by remarkably little amounts of either.
The damage can be direct (by steam) or indirect (by soot, which is nearly impossible to remove and will quickly damage any reader).
Fire safes are designed to protect "media" - like your passport or stock certificates. It is <i>not</i> designed for computer media, unless it explicitly states so. And these safes are very expensive.
The best solution is actually the cheapest. Go to Costco or the like and buy a bunch of quart and gallon "freezer" ziplock bags. Put the media in a paper sleeve, then quart bags, then in gallon bags, then in any fire safe. Try to have the "open end" of each bag on the far side of the surrounding bag.
Any single freezer bag should be enough to block steam and smoke from any fire which is survivable, the reason for nesting bags is that the outer bag might be very sooty after a fire. If you have the media immediately inside, the soot might transfer to it as you try to remove the media. But with a second layer of plastic, the media should be clean.
In this case, the "problem" can also be the "solution."
I've written some (Debian) packages which do nothing but set/clear the immutable flags of selected files when they're installed/removed.
Some examples:
lockdown-kernel will "chattr +i" the kernel images and modules, plus the configuration files used by the module loader. This helps stop installation of malicious kernel modules.
lockdown-users will "chattr +i" much of the user database. (Not/etc/shadow, for obvious reasons.) This helps stop malicious installation of users, or compromising existing ones.
lockdown-apt will "chattr +i" the configuration information used by "apt". This helps stop malicious modification of my system upgrade process.
lockdown-lib will "chattr +i" the core libraries, and the ldconfig information. This helps stop malicious modification of the core libraries - or the library search path.
I'm sure you get the idea. If I really do want to modify something, e.g., adding a user or installing a new kernel, I just remove the "lockdown" package, do the work, then reinstall it. This approach isn't perfect - unless I also change the capacities bounding set a malicious package can simply call "chattr" itself - but it's a good first step.
I'm reminded of an article I read on nuclear launch systems a while back. When the guys in the silo turn the key, the missiles launch, right?
Wrong. It sends launch codes to the missile, and those launch codes might say "go now," but they could also tell the missile to wait minutes, hours, days, years, even indefinitely. (The last would allow a single pod to launch them in the future, instead of the multiple pods required for the first launch command.)
The rationale is to provide a "second strike" capacity - the missiles will be launched when the enemy is attempting to rebuild the military base, etc. Evem if your launch crew is all dead, those missiles will launch.
An asteroid strike would be a very compelling second-strike weapon. Silos could be destroyed, blocked, disarmed, etc. But the asteroid-tweaking mission could be launched during the initial exchange and then it's out of reach until impact.
Remember that the NSA has multiple responsibilities. Specifically, it also has the responsibility to ensure that our (government, contractors) computers aren't compromised by others.
A truly secure COTS OS won't hurt the NSA and FBI too much - they have plenty of other resources available to them. But not many groups will be able to afford the HumInt required to get around NSA/FBI safeguards, if the easy technical backdoors have been eliminated.
I live in Boulder, a college town which has also seen riots protesting the Vietnam War, social injustice... and the police harrassing underage drinkers. (Guess which motivated the riots a few years ago.)
A couple quick points, to address common misperceptions:
<li>The riots might have occured in the student ghetto, but many of the rioters were not students. Some were young adults living in the area, others were bored idiots who rode the bus from Denver looking for excitement.
<li>These riots caused a lot of damage. Broken glass, overturned cars, etc. The trustafarians might not have been inconvenienced, but a lot of students and young adults are living near the edge anyway and losing their car - and the job it took them to - could be enough to force them out of college.
<li>A dumpster fire doesn't look dangerous, but many occured below overhanging trees or near buildings. Large fires can be unpredictable and it doesn't take much for one to jump to a house. It's about as "harmless" as firing a gun into a crowd and saying "no harm, no foul" because nobody was hit.
<li>Despite all of this, the crowd was still mostly peaceful. But every mob has its idiots and some of them threw rocks at the cops - some of which hit helmets with enough impact to cause damage. Hard enough to result in critical injuries to anyone not wearing a helmet.
Put all of this together, and the cops would have been legally justified in arresting everyone on the spot. But the cops also knew that this would likely result in deaths - some of these people would be carrying guns or knives, and in fact the police had positioned snipers on nearby rooftops against this possibility. A lot of people who were there just for "fun" would become violent if they perceived a threat.
Since the authorities and police wanted to minimize harm, they decided to contain the riots and look for the key players later. So they took pictures and put them up on their web page, on the city's cable TV channel, in the newspaper, etc. Many (most?) of the people sought were found and peacefully arrested, without the risk of escalating the violence of the mob.
Bottom line: we haven't had riots for several years. The ends don't always justify the means, but few residents find police taking pictures of riot after people have been ordered off the street (because of the riot, not "just because") to be an unreasonable burden.
You don't need to go overboard. IIRC the passphrase is ultimately reduced to an encryption key for the same block cipher you use for the messages.
You need phrases long enough to give you enough bits to cover the key space, but anything over that is unnecessary. Maybe 25-30 characters. That's long enough to make a dictionary attack on your passphrase about as costly as a brute force attack on the block cipher.
I've written PAM modules myself, so I know how flexible it is.
But I also know that many sites misuse PAM modules. PAM modules do not, cannot, encrypt traffic "over the wire" and anything sent to the module WILL be sniffed sooner or later. (I've lost track of the number of sites I've seen which use pam_krb5 with Apache, completely ignorant of the numerous ways it violates the Kerberos security model.) Local users (those connecting to Unix sockets) don't have to worry about these issues, but remote users do.
I have absolutely no idea what problem this "one time pad encryption" of the password solves. If the user sends the password in plaintext and the module compares encrypted passwords, a sniffer still captures the password. If the user has to encrypt the password himself, it breaks the PAM design principle that the user interface remains unchanged. (The user may be asked for a password, S/Key password, Kerberos passphrase, SecurID card, etc., but not required to run special programs to access the PAMified application. E.g., a program that encrypts the password with an arbitrary salt.)
PAM *does* support OTP passwords, but they're totally unrelated to the shadow passwords. S/Key passwords, for instance, are an excellent solution to this problem, but overkill for an IMAP account.
Do you REALLY want to have all of your users send their system login username and password in plaintext across the network?
If so, you might as well make/etc/shadow world-readable because it won't matter. You might as well tell everyone to use 'telnet,' not 'ssh,' for the same reason. Even if you're running inside of a firewall, trust everyone, etc., you still have to be alert to viruses/trojans, visitors leaving a laptop attached to an unused network port, and the like.
Some IMAP clients support SSL authentication/encryption and password sniffing isn't an issue. I don't know if Cyrus is one of them - you'll need to grab the source and look at the documentation.
But if you don't go the SSL route, set up a separate database for your IMAP passwords. Better yet, run the entire process in a "chroot jail" containing *only* the IMAP passwords, so the real passwords are protected even if someone exploits an IMAP vulnerability.
You're using the wrong technology for the problem. SSH is great for connecting to the occasional remote host (e.g., to your ISP shell account, to your office computer from home and vice versa), but it was never designed to handle this type of situation.
In this case you really should be using a central authentication method. Kerberos is one well-known example, and there are others as well. In this case you would/could still generate new host keys, but you would only have to update a single server (two, including a backup server).
The flip side of this problem is that you really don't want to allow just anyone to connect to a server cluster - with SSH you can specify acceptable user keys, but it's even more of a nightmare to propogate this information to each system. With a central server, you can disable a user's account systemwide (or on some defined subnet) with a single update. No worries that the guy who had to be fired left a backdoor SSH keyfile on a server or three.
Conversion to Kerberos isn't trivial, but it has some additional benefits. E.g., SSH just gives you communications, but Kerberos authentication is also available to properly configured applications (ktelnet, kftp, ksu, plus sudo, cvs, postgres, lprng, pop/imap, etc. Even NFS, on some non-Linux systems.) I've found a Kerberized system *easier* to use because I'm rarely asked for passwords except when logging in, or asking for root privileges. No need to keep track of separate passwords, lest someone trivially break the CVS password and figure out my account's password.
If you read the article, there's a common refrain. A director of manufacturing was blocked. A new company's CEO and two other executives were blocked. These are not programmers, or even analysts and technical managers. These are senior people who would be highly knowledgeable about their former employer's business details.
The exceptions are a couple people in sales in a highly specialized market who were accused of taking a customer list (which was not properly protected by the former employee), and that case where Microsoft threw its weight around and forced a company to cut 1/4 of its staff, former Microsoft employees, to avoid spending all of its time in court.
While this isn't something we can ignore - with small startup staffs, today's grunt programmer may be an "executive" at tomorrow's startup - it's hardly a return to the days when companies tried to insist that "you learned C on this job, you can't use C for 2 years!"
The reason so many of us have strong opinions is because these issues have affected us personally again and again and yet again. This tends to make you motivated to learn more. It's no different from someone with a disease wishing to learn more about it -- and often becoming more knowledgeable about that disease than their primary care physician. These people aren't doctors... yet good doctors will recognize their value as resources for their own care.
As for the depth of knowledge, I agree that many posters haven't studied civil liberties beyond the 10th grade civics class introduction. But many of us, because of needs-based motivation, have studied it in much more detail. I've sat in on a college pre-law course on civil liberties, via a cable TV channel. I've read several books written by lawyers specializing in constitutional law on how civil liberties apply to cyberspace. I follow the EFF. I pay close attention to the opinions, esp. dissenting opinions, whenever the Supreme Court issues rulings on these issues.
I am not a lawyer... but I am probably more current on civil liberties issues than most practicing attorneys since they probably haven't had to think about this stuff since their bar exam. Even lawyers who specialize in Constitutional Law may not be paying close attention to civil liberties as they apply to cyberspace. You would be a fool to not get advice from a lawyer if you need it... but it's equally foolish to run to a lawyer several times a week for every single question (and the more you know about this topic, the more questions you have!), or to censor yourself so severely that the question never comes up because you live in an unwired trailer deep in the woods.
Bottom line: like every other public forum 90+% of the stuff here is crap. But not 100%.
You can't make a fresh start. Remember that psycho date you had in college? Her comments about you can now be reviewed by any future date, including the woman who would have become your wife. Don't count on the potential date remembering to check the trustworthiness of the reporter.
You can't trust the data. Credit reports today have significant errors in about a third of them. My own credit reports originally showed several accounts I never opened, but which were simply misfiled. Other entries involved a dispute, but the "fair credit reporting act" has some loopholes that allow the CRA to ignore consumer comments. When more data is collected, more errors will occur and the portrait they paint is increasingly inaccurate.
You can't trust the data. The more important this data becomes to everyday life, the more pressure there will be to manipulate it. For every legitimate change (e.g., hiding information about tempting kidnapping target) there will be hundreds or thousands of fradulent changes. Look at the primary effect of the law requiring documentation before anyone can be hired in the US - an explosion in identity theft as illegal aliens masquerade as citizens so they can be hired - and multiply it a thousand-fold.
Society will become ultra-conformist. Because nobody has a private life, everyone will act like the proverbial Oldsmobile dealer in a small Texas town. He might not be religious, but he'll be prominent in church every week because his many of his customers are. He might not like football, but he'll be a leading member of the HS's booster club because many of his customers do. When your future boss can find out what church you attend, what books you read, what movies you watch, what music you enjoy ('cause you now download it all and those records are available), etc., and the reason why you aren't hired is one of the few things that isn't transparent, you'll find yourself under immense pressure to always second-guess how others will perceive your actions.
Unfortunately, I agree that we're moving towards a world of transparent information on the wage-slave class. But the information will most assuredly not be transparent for those with power, money, or criminal intent.
It's really nice of Microsoft to do that, and to add the automatic update functionality in Windows ME, but that misses the key problems.
First, Microsoft does not adequately test its service packs. There was a very embarassing series of "service packs required to fix prior service pack" with NT4. I think it ran from SP4 through SP7. If installing a service pack may take down your system, only an idiot will allow it to be done automatically or "casually."
Second, Microsoft is notorious for doing more than simple bug fixes in its service packs. Sometimes that functionality is useful, more often it breaks installed third-party applications. Again, only an idiot will allow it to be done automatically or "casually."
In many ways, this "feature" reminds me of the joke about the helicopter pilot lost in the fog over the Microsoft campus. This feature might look helpful to the casual observer, but it ignores the real problems.
Some Unix systems (but not yet Linux) support strongly authenticated extensions of the RPC protocol. NFS+ is built on top of RPC-DES(?) from Sun, and uses a form of PKI and DES session encryption; it is nominally in glibc 2.1.2 et seq. (iirc), but the necessary infrastructure is not yet present. This uses a distributed PKI system.
Another uses GSSAPI authentication, usually using Kerberos. This uses a centralized authentication server.
Both allow you to set up your server so that only specific users can mount the drives, and I believe they also allow you to specify that encrytion should be used on the wire.
Since both involve extensions to RPC, you can easily add strong authentication and encryption to other RPC-based applications.
Something to remember about man pages is that it's trivial to produce a nicely formatted, easy-to-read hardcopy version: groff -man manpage.1 | gs
The other formats might be a little easier to read online, but I've always found the hardcopy versions a little harder to read.
This might be generational - for the first decade of my career man pages were the only option, and I learned the standard C library from a printed version of those pages.
If you break into a locked house, it's breaking and entering.
If you enter an unlocked house, without permission, it's entering. Still a crime. The fact that you left the door open is not "permission," not even implicitly. The fact that someone left his computer in its default configuration is sure as hell not permission. Someone specifically enabling sharing for their home-based network is a bit more debatable, but I still doubt it would take any reasonable person more than a few seconds to decide that it's not permission for everyone to enter.
If you take stuff without permission it's theft, even if the person didn't know he/she possessed the item. It's theft even if all you do is copy the papers on the desk.
Even leaving something in the house is a crime. Littering, if nothing else.
Finally, even if all they do is tell their friends where to find open doors, if they do that in the expectation that their friends will commit crimes (entering, theft, etc.), then they're still party to a conspiracy.
It's not just the liquor laws that keep a lot of people far away from Utah. It's the mindset of a state that is appointed a 40-year-old virgin as porn queen. And they think WE don't have a social life!
A virgin Mormon porn czar?? [Are they kidding?!]
SALT LAKE CITY, UT -- Utah's new porn czar is an acknowledged virgin who rarely watches R-rated movies and has prosecuted a scant five pornography cases in her 15-year legal career. But Paula Houston asserts she knows smut when she sees it.
Utah - a state that regularly appoints teetotallers to its alcohol-regulatory board - is the nation's pioneer in creating an "obscenity and pornography complaints ombudsman."
Besides her experience as a city prosecutor, Houston, 40, unabashedly brings the values of her Mormon faith to an assignment that will include viewing XXX-rated movies, pornographic Internet sites and sexually explicit magazines. Houston's lack of personal sexual experience disqualifies her in the minds of some from passing judgment on just what constitutes pornography. Others say moral judgments are best made by those who are above reproach. For Houston, such arguments are entirely beside the point.
"My personal life is irrelevant," says Houston. [What personal life?]
From an article by Kevin Cantera & Michael Vigh, Salt Lake Tribune, 2/11/01
P.S., the "lameness filter" is a piece of crap! Just because Netscape inserts leading whitespace in copied material is no reason to reject comments!
First, you run into combinatorical explosion in the real world. Try running through your example in a small CS department with 5 professors, 50 students, and each student enrolled in three classes. Everyone has to work in teams, but the teams are different in each class. So each student needs to see his own files, and *some* of the files in 6-12 other user accounts (with team sizes from 3-5 people). He can't see all because that would be "cheating."
Now maintain that over 5 years, as students enroll, graduate, etc.
The second problem is that ACLs often support much more than simple read/write/execute. There's "modify" vs. "append." That is so important that ext2 supports "append-only" as one of the extended attributes. There's "change attributes (chattr)" as a separate permission than "write." Some ACL systems even control your ability to "stat" a file, to determine its ownership, size, time of access, etc. Some of this can be handled by your scheme, but it makes it much more complex.
The final problem is that ACLs are far more powerful than most implementations would suggest. Besides being able to grant - or revoke - access to individuals for read/write/execute/modify/append/delete/chattr/sta t, I've seen ACL specs which allowed restriction based on time-of-day, day-of-week, and even access terminal (local vs. network). You can use 'cron' to automatically change some bits, but it's hard to set it up so that, e.g., the faculty can play games any time, the staff can play them after hours, and the students can play them on weekends.
Fat/vfat file systems don't have the concept of an "owner," but NTFS does. Ideally this ownership information (and ACL permissions) will be retained even if someone sticks an NTFS-formatted zip disk into a Linux box.
The problem is that there's no obvious connection between NTFS ownerships and the user/group of the host Linux system. If you trust root to identify the mapping you leave the system open to attack by anyone with local root access. This would prevent Linux from being adopted in some environments.
A similar problem occurs with the network file systems. You want to avoid the biggest headache in NFS, the ability of someone with local root access to impersonate any other user. It's possible, but it requires the system distinguish between network and local user ids.
One concept I would love to see implemented is "watchdogs." This is the ability to specify a program which should be run whenever a file or directory is accessed, opened for reads, opened for writes, written to, etc. Basically anything at the VFS level.:-)
Logging is trivial to implement.
ACLs are trivial to implement. The program looks at the user and can indicate (via return code) whether to permit access.
Compression and encryption are relatively easy to implement, if you also retain some state information betweens calls.
Even virtual files and directories can be implemented. This could be used to implement things like "ftp" and "http" mounts.
There's a lot of similarities with "user space" file systems, and that concept might be preferred now.
The problem is that Unix filesystems only provide course control. ACLs provide much finer control.
An example of where ACLs would be required would be a well-run law or medical office. Each person would have their own user id, and would be in a couple groups. (Doctors, lawyers, secretaries, nurses, paralegals, etc., plus departmental groups.)
But confidentially still means that many files should be accessible only to a few people, e.g., one lawyer, one paralegal and one legal secretary. If someone goes on vacation, their replacement needs to have access during the period they're covering the regular person, but no longer. If someone else needs to be brought in for consultation, they might need read-only access for a while.
Try doing that with Unix permissions. It's possible, but it is *extremely* difficult and runs into combinatorical explosion with more than a handful of people. (Basically you need to create a "group" with every possible subset of users. You then change the group permissions to implement these semantics.)
Slashdot Mirror
Several people have already mentioned part of this approach, but not combined it.
1) Suspend a steady platform with bungee cords, ropes, whatever. It's far more important for it to be flexible than stretchy. You probably want to attach a few cords on the bottom to stop swinging - these should be stretchy.
2) Add extra mass to this platform - something like a layer of bricks. This will put the suspension cords under more tension (which allows them to transmit more vibrational energy), but the extra mass of the system should decrease the motion seen.
3) On top of this platform, put the partly inflated inner tube mentioned elsewhere. This platform holds the computers.
This is more complex than a single suspension system, but a single system will still transmit some key harmonic frequencies. But it's unlikely that two independent systems will share harmonics so there should be very little energy transmitted into the disks.
I can think of at least two excellent reasons off the top of my head.
First, it's a considerable expense and hassle. Patent attorneys are not optional - the claims have to be properly worded for the USPTO office to accept them *and* to prevent some business from stealing your idea by rewording an ineffectual claim ever so slightly. If you're a business and want to create market entry barriers to your competition, $10-20k might be a good investment. If you're a working stiff, that's a lot harder to justify. If you're still in college, forget it!
Second, by seeking patents for "obvious" things we're implicitly accepting the validity of all other obvious patents. A sadly too common analogy is elections in corrupt regimes - you can organize a voter boycott because the election is corrupt, you can run your own candidate, but you can't do both.
This point needs to be reiterated.
"Freedom of Assembly" has always been held to mean two things. You can have a meeting with like-minded people, and you can eject all others. This protected the NAACP membership list in the 50s and 60s, and the KKK membership list a few years ago.
"Freedom of Religion" means that you can attend the church of your choice - or none at all. At the same time you can refuse to attend any or all churches.
"Freedom of the Press" means that you can print truthful information that embarasses the government. You can also refuse to publish things that the government wants you to publish. <u>High Times</u> Magazine does not have to include a monthly message from the Drug Czar, etc.
"Freedom to Petition for Redress" means that you can ask your Congressional delegates to pass a law, etc. But it doesn't require you to write them about every passing thought you have.
So why do so many people think that "Freedom of Speech," the final element of the First Amendment, means that you have to listen to every idiot standing on a soapbox?! OF COURSE "Freedom of Speech" includes the right to ignore the other person. And not just passively - unwanted guests at assemblies can be forcefully removed by the police and prosecuted for 'trespassing,' so it's not unreasonable to invoke the power of the state to suppress people who just won't accept that their message is unwanted.
A few years ago, spam was tolerated because the social cost of hitting "delete" a couple times each day was less than the cost of fighting it. It was often compared to the effort involved in tossing a couple of pieces of daily junk mail in the trash.
But now many people are seeing three or four times more spam than real messages. It's not unreasonable to expect this ratio to be much worse in the next few years. Imagine finding your snail mail box full of mail, with hundreds of envelopes, each and every day. You have to spend at least an hour, each and every day, looking for your bills, correspondence, etc. Many of the envelopes are intentionally disguised to look like important messages. (E.g., it's a letter from the IRS - announcing an "Inventory Reduction Sale" at the local "Herb Tarlek" Car Lot!")
If this isn't unreasonable, what is?
If the administrators won't do their job - ensuring a safe public education for ALL students - then REMOVE THEM FROM OFFICE!. If the principal won't do his job, fire him for cause! (Something that the school board can do).
The principal and school board will drag out this case for years in the court, and will do everything they can to keep others from learning the details. They'll even claim it's for Sean's protection.
But they can't stop the media from covering a candidate for political office demanding accountability by principals when they attempt to violate the Constitutional rights of students. They can't stop the media from doing "candidate profiles" where Patrick explains that he's running the school board because his son was hounded out of the school by teenage morons and spineless administrators -- and he wants to protect other families from the pain his suffered.
As an aside, our local school board got out of control a few years ago. They eventually sacked the popular principal of one of the high schools, installing their own crony. None of them survived the next election cycle, and that ex-principal became the new head of the school board. School board elections are normally low on the political radar - unless you have children in the public schools, they rarely grab your attention. But that means that one person, with a good cause, can bring in enough extra voters to replace boards en masse.
Something many people overlook is that paper isn't damaged, too much, by steam and smoke, but computer media is destroyed by remarkably little amounts of either.
The damage can be direct (by steam) or indirect (by soot, which is nearly impossible to remove and will quickly damage any reader).
Fire safes are designed to protect "media" - like your passport or stock certificates. It is <i>not</i> designed for computer media, unless it explicitly states so. And these safes are very expensive.
The best solution is actually the cheapest. Go to Costco or the like and buy a bunch of quart and gallon "freezer" ziplock bags. Put the media in a paper sleeve, then quart bags, then in gallon bags, then in any fire safe. Try to have the "open end" of each bag on the far side of the surrounding bag.
Any single freezer bag should be enough to block steam and smoke from any fire which is survivable, the reason for nesting bags is that the outer bag might be very sooty after a fire. If you have the media immediately inside, the soot might transfer to it as you try to remove the media. But with a second layer of plastic, the media should be clean.
In this case, the "problem" can also be the "solution."
/etc/shadow, for obvious reasons.) This helps stop malicious installation of users, or compromising existing ones.
I've written some (Debian) packages which do nothing but set/clear the immutable flags of selected files when they're installed/removed.
Some examples:
lockdown-kernel will "chattr +i" the kernel images and modules, plus the configuration files used by the module loader. This helps stop installation of malicious kernel modules.
lockdown-users will "chattr +i" much of the user database. (Not
lockdown-apt will "chattr +i" the configuration information used by "apt". This helps stop malicious modification of my system upgrade process.
lockdown-lib will "chattr +i" the core libraries, and the ldconfig information. This helps stop malicious modification of the core libraries - or the library search path.
I'm sure you get the idea. If I really do want to modify something, e.g., adding a user or installing a new kernel, I just remove the "lockdown" package, do the work, then reinstall it. This approach isn't perfect - unless I also change the capacities bounding set a malicious package can simply call "chattr" itself - but it's a good first step.
I'm reminded of an article I read on nuclear launch systems a while back. When the guys in the silo turn the key, the missiles launch, right?
Wrong. It sends launch codes to the missile, and those launch codes might say "go now," but they could also tell the missile to wait minutes, hours, days, years, even indefinitely. (The last would allow a single pod to launch them in the future, instead of the multiple pods required for the first launch command.)
The rationale is to provide a "second strike" capacity - the missiles will be launched when the enemy is attempting to rebuild the military base, etc. Evem if your launch crew is all dead, those missiles will launch.
An asteroid strike would be a very compelling second-strike weapon. Silos could be destroyed, blocked, disarmed, etc. But the asteroid-tweaking mission could be launched during the initial exchange and then it's out of reach until impact.
Remember that the NSA has multiple responsibilities. Specifically, it also has the responsibility to ensure that our (government, contractors) computers aren't compromised by others.
A truly secure COTS OS won't hurt the NSA and FBI too much - they have plenty of other resources available to them. But not many groups will be able to afford the HumInt required to get around NSA/FBI safeguards, if the easy technical backdoors have been eliminated.
I live in Boulder, a college town which has also seen riots protesting the Vietnam War, social injustice... and the police harrassing underage drinkers. (Guess which motivated the riots a few years ago.)
A couple quick points, to address common misperceptions:
<li>The riots might have occured in the student ghetto, but many of the rioters were not students. Some were young adults living in the area, others were bored idiots who rode the bus from Denver looking for excitement.
<li>These riots caused a lot of damage. Broken glass, overturned cars, etc. The trustafarians might not have been inconvenienced, but a lot of students and young adults are living near the edge anyway and losing their car - and the job it took them to - could be enough to force them out of college.
<li>A dumpster fire doesn't look dangerous, but many occured below overhanging trees or near buildings. Large fires can be unpredictable and it doesn't take much for one to jump to a house. It's about as "harmless" as firing a gun into a crowd and saying "no harm, no foul" because nobody was hit.
<li>Despite all of this, the crowd was still mostly peaceful. But every mob has its idiots and some of them threw rocks at the cops - some of which hit helmets with enough impact to cause damage. Hard enough to result in critical injuries to anyone not wearing a helmet.
Put all of this together, and the cops would have been legally justified in arresting everyone on the spot. But the cops also knew that this would likely result in deaths - some of these people would be carrying guns or knives, and in fact the police had positioned snipers on nearby rooftops against this possibility. A lot of people who were there just for "fun" would become violent if they perceived a threat.
Since the authorities and police wanted to minimize harm, they decided to contain the riots and look for the key players later. So they took pictures and put them up on their web page, on the city's cable TV channel, in the newspaper, etc. Many (most?) of the people sought were found and peacefully arrested, without the risk of escalating the violence of the mob.
Bottom line: we haven't had riots for several years. The ends don't always justify the means, but few residents find police taking pictures of riot after people have been ordered off the street (because of the riot, not "just because") to be an unreasonable burden.
You don't need to go overboard. IIRC the passphrase is ultimately reduced to an encryption key for the same block cipher you use for the messages.
You need phrases long enough to give you enough bits to cover the key space, but anything over that is unnecessary. Maybe 25-30 characters. That's long enough to make a dictionary attack on your passphrase about as costly as a brute force attack on the block cipher.
I've written PAM modules myself, so I know how flexible it is.
But I also know that many sites misuse PAM modules. PAM modules do not, cannot, encrypt traffic "over the wire" and anything sent to the module WILL be sniffed sooner or later. (I've lost track of the number of sites I've seen which use pam_krb5 with Apache, completely ignorant of the numerous ways it violates the Kerberos security model.) Local users (those connecting to Unix sockets) don't have to worry about these issues, but remote users do.
I have absolutely no idea what problem this "one time pad encryption" of the password solves. If the user sends the password in plaintext and the module compares encrypted passwords, a sniffer still captures the password. If the user has to encrypt the password himself, it breaks the PAM design principle that the user interface remains unchanged. (The user may be asked for a password, S/Key password, Kerberos passphrase, SecurID card, etc., but not required to run special programs to access the PAMified application. E.g., a program that encrypts the password with an arbitrary salt.)
PAM *does* support OTP passwords, but they're totally unrelated to the shadow passwords. S/Key passwords, for instance, are an excellent solution to this problem, but overkill for an IMAP account.
Stop and think about what you're trying to do!
/etc/shadow world-readable because it won't matter. You might as well tell everyone to use 'telnet,' not 'ssh,' for the same reason. Even if you're running inside of a firewall, trust everyone, etc., you still have to be alert to viruses/trojans, visitors leaving a laptop attached to an unused network port, and the like.
Do you REALLY want to have all of your users send their system login username and password in plaintext across the network?
If so, you might as well make
Some IMAP clients support SSL authentication/encryption and password sniffing isn't an issue. I don't know if Cyrus is one of them - you'll need to grab the source and look at the documentation.
But if you don't go the SSL route, set up a separate database for your IMAP passwords. Better yet, run the entire process in a "chroot jail" containing *only* the IMAP passwords, so the real passwords are protected even if someone exploits an IMAP vulnerability.
You're using the wrong technology for the problem. SSH is great for connecting to the occasional remote host (e.g., to your ISP shell account, to your office computer from home and vice versa), but it was never designed to handle this type of situation.
In this case you really should be using a central authentication method. Kerberos is one well-known example, and there are others as well. In this case you would/could still generate new host keys, but you would only have to update a single server (two, including a backup server).
The flip side of this problem is that you really don't want to allow just anyone to connect to a server cluster - with SSH you can specify acceptable user keys, but it's even more of a nightmare to propogate this information to each system. With a central server, you can disable a user's account systemwide (or on some defined subnet) with a single update. No worries that the guy who had to be fired left a backdoor SSH keyfile on a server or three.
Conversion to Kerberos isn't trivial, but it has some additional benefits. E.g., SSH just gives you communications, but Kerberos authentication is also available to properly configured applications (ktelnet, kftp, ksu, plus sudo, cvs, postgres, lprng, pop/imap, etc. Even NFS, on some non-Linux systems.) I've found a Kerberized system *easier* to use because I'm rarely asked for passwords except when logging in, or asking for root privileges. No need to keep track of separate passwords, lest someone trivially break the CVS password and figure out my account's password.
If you read the article, there's a common refrain. A director of manufacturing was blocked. A new company's CEO and two other executives were blocked. These are not programmers, or even analysts and technical managers. These are senior people who would be highly knowledgeable about their former employer's business details.
The exceptions are a couple people in sales in a highly specialized market who were accused of taking a customer list (which was not properly protected by the former employee), and that case where Microsoft threw its weight around and forced a company to cut 1/4 of its staff, former Microsoft employees, to avoid spending all of its time in court.
While this isn't something we can ignore - with small startup staffs, today's grunt programmer may be an "executive" at tomorrow's startup - it's hardly a return to the days when companies tried to insist that "you learned C on this job, you can't use C for 2 years!"
The reason so many of us have strong opinions is because these issues have affected us personally again and again and yet again. This tends to make you motivated to learn more. It's no different from someone with a disease wishing to learn more about it -- and often becoming more knowledgeable about that disease than their primary care physician. These people aren't doctors... yet good doctors will recognize their value as resources for their own care.
As for the depth of knowledge, I agree that many posters haven't studied civil liberties beyond the 10th grade civics class introduction. But many of us, because of needs-based motivation, have studied it in much more detail. I've sat in on a college pre-law course on civil liberties, via a cable TV channel. I've read several books written by lawyers specializing in constitutional law on how civil liberties apply to cyberspace. I follow the EFF. I pay close attention to the opinions, esp. dissenting opinions, whenever the Supreme Court issues rulings on these issues.
I am not a lawyer... but I am probably more current on civil liberties issues than most practicing attorneys since they probably haven't had to think about this stuff since their bar exam. Even lawyers who specialize in Constitutional Law may not be paying close attention to civil liberties as they apply to cyberspace. You would be a fool to not get advice from a lawyer if you need it... but it's equally foolish to run to a lawyer several times a week for every single question (and the more you know about this topic, the more questions you have!), or to censor yourself so severely that the question never comes up because you live in an unwired trailer deep in the woods.
Bottom line: like every other public forum 90+% of the stuff here is crap. But not 100%.
Unfortunately, I agree that we're moving towards a world of transparent information on the wage-slave class. But the information will most assuredly not be transparent for those with power, money, or criminal intent.
It's really nice of Microsoft to do that, and to add the automatic update functionality in Windows ME, but that misses the key problems.
First, Microsoft does not adequately test its service packs. There was a very embarassing series of "service packs required to fix prior service pack" with NT4. I think it ran from SP4 through SP7. If installing a service pack may take down your system, only an idiot will allow it to be done automatically or "casually."
Second, Microsoft is notorious for doing more than simple bug fixes in its service packs. Sometimes that functionality is useful, more often it breaks installed third-party applications. Again, only an idiot will allow it to be done automatically or "casually."
In many ways, this "feature" reminds me of the joke about the helicopter pilot lost in the fog over the Microsoft campus. This feature might look helpful to the casual observer, but it ignores the real problems.
Some Unix systems (but not yet Linux) support strongly authenticated extensions of the RPC protocol. NFS+ is built on top of RPC-DES(?) from Sun, and uses a form of PKI and DES session encryption; it is nominally in glibc 2.1.2 et seq. (iirc), but the necessary infrastructure is not yet present. This uses a distributed PKI system.
Another uses GSSAPI authentication, usually using Kerberos. This uses a centralized authentication server.
Both allow you to set up your server so that only specific users can mount the drives, and I believe they also allow you to specify that encrytion should be used on the wire.
Since both involve extensions to RPC, you can easily add strong authentication and encryption to other RPC-based applications.
Something to remember about man pages is that it's trivial to produce a nicely formatted, easy-to-read hardcopy version:
groff -man manpage.1 | gsThe other formats might be a little easier to read online, but I've always found the hardcopy versions a little harder to read.
This might be generational - for the first decade of my career man pages were the only option, and I learned the standard C library from a printed version of those pages.
If you break into a locked house, it's breaking and entering.
If you enter an unlocked house, without permission, it's entering. Still a crime. The fact that you left the door open is not "permission," not even implicitly. The fact that someone left his computer in its default configuration is sure as hell not permission. Someone specifically enabling sharing for their home-based network is a bit more debatable, but I still doubt it would take any reasonable person more than a few seconds to decide that it's not permission for everyone to enter.
If you take stuff without permission it's theft, even if the person didn't know he/she possessed the item. It's theft even if all you do is copy the papers on the desk.
Even leaving something in the house is a crime. Littering, if nothing else.
Finally, even if all they do is tell their friends where to find open doors, if they do that in the expectation that their friends will commit crimes (entering, theft, etc.), then they're still party to a conspiracy.
A virgin Mormon porn czar?? [Are they kidding?!]
SALT LAKE CITY, UT -- Utah's new porn czar is an acknowledged virgin who rarely watches R-rated movies and has prosecuted a scant five pornography cases in her 15-year legal career. But Paula Houston asserts she knows smut when she sees it.
Utah - a state that regularly appoints teetotallers to its alcohol-regulatory board - is the nation's pioneer in creating an "obscenity and pornography complaints ombudsman."
Besides her experience as a city prosecutor, Houston, 40, unabashedly brings the values of her Mormon faith to an assignment that will include viewing XXX-rated movies, pornographic Internet sites and sexually explicit magazines. Houston's lack of personal sexual experience disqualifies her in the minds of some from passing judgment on just what constitutes pornography. Others say moral judgments are best made by those who are above reproach. For Houston, such arguments are entirely beside the point.
"My personal life is irrelevant," says Houston. [What personal life?]
From an article by Kevin Cantera & Michael Vigh, Salt Lake Tribune, 2/11/01
P.S., the "lameness filter" is a piece of crap! Just because Netscape inserts leading whitespace in copied material is no reason to reject comments!
There are three small problems with this scheme.
a t, I've seen ACL specs which allowed restriction based on time-of-day, day-of-week, and even access terminal (local vs. network). You can use 'cron' to automatically change some bits, but it's hard to set it up so that, e.g., the faculty can play games any time, the staff can play them after hours, and the students can play them on weekends.
First, you run into combinatorical explosion in the real world. Try running through your example in a small CS department with 5 professors, 50 students, and each student enrolled in three classes. Everyone has to work in teams, but the teams are different in each class. So each student needs to see his own files, and *some* of the files in 6-12 other user accounts (with team sizes from 3-5 people). He can't see all because that would be "cheating."
Now maintain that over 5 years, as students enroll, graduate, etc.
The second problem is that ACLs often support much more than simple read/write/execute. There's "modify" vs. "append." That is so important that ext2 supports "append-only" as one of the extended attributes. There's "change attributes (chattr)" as a separate permission than "write." Some ACL systems even control your ability to "stat" a file, to determine its ownership, size, time of access, etc. Some of this can be handled by your scheme, but it makes it much more complex.
The final problem is that ACLs are far more powerful than most implementations would suggest. Besides being able to grant - or revoke - access to individuals for read/write/execute/modify/append/delete/chattr/st
Fat/vfat file systems don't have the concept of an "owner," but NTFS does. Ideally this ownership information (and ACL permissions) will be retained even if someone sticks an NTFS-formatted zip disk into a Linux box.
The problem is that there's no obvious connection between NTFS ownerships and the user/group of the host Linux system. If you trust root to identify the mapping you leave the system open to attack by anyone with local root access. This would prevent Linux from being adopted in some environments.
A similar problem occurs with the network file systems. You want to avoid the biggest headache in NFS, the ability of someone with local root access to impersonate any other user. It's possible, but it requires the system distinguish between network and local user ids.
One concept I would love to see implemented is "watchdogs." This is the ability to specify a program which should be run whenever a file or directory is accessed, opened for reads, opened for writes, written to, etc. Basically anything at the VFS level. :-)
Logging is trivial to implement.
ACLs are trivial to implement. The program looks at the user and can indicate (via return code) whether to permit access.
Compression and encryption are relatively easy to implement, if you also retain some state information betweens calls.
Even virtual files and directories can be implemented. This could be used to implement things like "ftp" and "http" mounts.
There's a lot of similarities with "user space" file systems, and that concept might be preferred now.
The problem is that Unix filesystems only provide course control. ACLs provide much finer control.
An example of where ACLs would be required would be a well-run law or medical office. Each person would have their own user id, and would be in a couple groups. (Doctors, lawyers, secretaries, nurses, paralegals, etc., plus departmental groups.)
But confidentially still means that many files should be accessible only to a few people, e.g., one lawyer, one paralegal and one legal secretary. If someone goes on vacation, their replacement needs to have access during the period they're covering the regular person, but no longer. If someone else needs to be brought in for consultation, they might need read-only access for a while.
Try doing that with Unix permissions. It's possible, but it is *extremely* difficult and runs into combinatorical explosion with more than a handful of people. (Basically you need to create a "group" with every possible subset of users. You then change the group permissions to implement these semantics.)