First off, I doubt there's one organization in 10,000 that could survive if it had to have two or more people to agree every time an action by the superuser were required. I don't know how many times I use root privs during the day. Your post sounds more like a made-up example than a serious alternative.
Secondly, you still haven't eliminated the trust issue, you've just pushed it back a little. Don't forget that there's a whole level of hardware trust involved. I already mentioned taking the system hard disk out for "maintenance" but there are other avenues as well.
Thirdly, you're also assuming that two or more "independent" parties won't actually be acting in collusion. For a large enough payoff, say US $150 Million, would you be willing to bet that the system manager at your investment brokerage couldn't find someone to collaborate with? I wouldn't make that wager.
Actually, I don't think it's nearly as easy as you make it sound. Ok, assume we have set up such a dual-approver system. It has to run on some computer, right? There has to be someone somewhere who can administer that computer. The super user can always tamper with the software in ways you won't be able to detect.
Even assuming the absence of an all-powerful superuser, there are problems. Someone has to be responsible for installing, maintaining and perhaps upgrading the application that manages the dual-approver system, so there's at least one person who doesn't need any confirmation before setting you up the bomb.
And even if you solve that problem, there's the problem with untrustworthy hardware. Someone somewhere has physical access to the box, which would provide them with the ability to, say, take the disk drive "for maintenance", mount it in their own box, diddle whatever code they want, and return the "fixed" drive to service.
And that brings up the problem of... and then the problem of... not to mention the problem of... it just keeps going. With our current technology, it's literally impossible to eliminate the issue of trust in our computing environments. They say everyone has their price. Scary thought, isn't it?
This isn't actually as big a shock as it appears, at least not if you've been following grid computing. IBM has already invested heavily in grid services and software. That's what this is aimed at.
They've been known to make this sort of heavy financial commitment to important technologies before (like Linux), so I expect this to be more of the same. In particular, it's good because it means they'll be in the Grid business for quite a while. Also, grids are hard to get right if you're designing them yourself, so having IBM do it for you will probably work out to being a substantial savings, both in time and money.
The only reason I can think of is to learn it so one can put "Solaris" on the "list of things I know" when looking for a new job...
That is, in fact, a very good reason. Keeping current with the latest Solaris releases is quite a useful thing to do.
I also have another reason that probably won't apply to everyone here. I do freelance writing and a lot of it has to do with information security. When I need to try new tools or techniques, I never want to try them on my real computers if there's even any *chance* they might be dangerous. I use VMWare virtual machines running Linux and Windows. I'm going to be
adding Solaris x86 to that mix soon, since virtually every result I'd gather from those systems will apply equally well to the SPARC systems most people have. I'm really looking forward to adding Solaris to my "virtual test lab".
First, open source project teams should try their best to make sure that their distribution points are secure. I know that no one intentionally distributes code from known-bad servers, but rather than just assuming security in the absence of knowledge to the contrary, I think they should make the security of their servers more of an active part of their project.
Second, they should register PGP keys with the key servers. Popular projects could even sign each other's keys, creating an informal web of trust. For example, the FreeBSD, OpenSSL and OpenSSH teams could maybe sign each others keys. This would help users make sure they don't download false keys from the servers.
Project teams should keep their private keys on read-only media (like a CD-R), and only 2 or 3 trusted members should be allowed to sign distributions. Really large projects could even do key splitting, so that (for example) 3 out of 5 developers are required in order to sign a release.
Of course, the project files should have detached signatures available in the same place that the distribution is. If it's FTP, put the detached signature in the same directory as the tarball. A lot of projects already do this. A pointer to the signature should be included in the project. Preferably, this should be in a standard file, like the $PROJECTROOT/SIGNATURE file, to make it easy to find.
If all these suggestions (or something like them) were followed, then someone who downloaded a package could use an automated tool to check the signature in one easy step. It is almost axiomatic that convenient security procedures get followed far more often than inconvenient ones, so I think automation is an important consideration here. It would add only one easy step, transmuting
Ok, I know a lot of people have already replied, but here's a point that I didn't see anyone make explicitly yet, though it was left unsaid a couple of times. It's also my favorite answer to the question "Why care about anime?"
The point is this: Animation allows more types of stories to be told within a limited budget. Animation is way cheaper than live action, especially for stories that aren't set in today's world or that require a lot of special effects for whatever reason. This could be sci-fi, like Cowboy Bebop, but also historical. It could be action (explosions and car wrecks cost too much) or romance. It doesn't matter. The lower cost of animation allows more stories (in any genre) to see the light of day.
I'm a huge Cowboy Bebop fan. I've got all the soundtrack CDs, too. I'm disapointed I can't see the NYC premiere. I'd love to meet Yoko Kanno, but oh well.
I agree with various comments already made about how you can't really count on the laptop's configuration itself to keep the students from using email, etc. It's too easy to reinstall an OS without the locked-down configuration, for one thing. If you can't do it at the host level, the network level is an obvious next step.
Just a wild idea, but what about a modified intrusion detection system? Rather than detecting people coming into the network, it could look for anomalous behavior, such as ICQ traffic during class periods. You might not be able to stop it, but you could probably detect it. I think you could write rules for pretty much anything you'd need to detect in Snort, for example.
I got my start as an admin in college. I was a
CS major, and the CS department network was run
entirely by students (supervised by a full-time
staff member who was management only, and not
too technical). I started as a lab consultant,
helping people with their editors and compilers
and such. It was more of a general helpdesk
position, with light administration duties. I
was promoted fairly soon after to a real
administrator, with the root passwords and
everything. By the end of my college time, I
was the head of this group, which made getting
my first admin job outside pretty easy.
During this time, I also helped a friend of mine
(who was an English major at the time) learn to
use the Unix workstations and the Internet.
He parlayed this into a position within the
help desk organization and then eventually into
the administrator group also. So it's possible
to do if you have one person who can give you
the first break.
If you're not in a university environment,
probably your best bet is to try to get involved
in the Linux community somehow, get your name
attached to some projects that you can use as
partial credentials on your resume. Also, if
you're not already running a network of at
least a couple of Linux machines at home, you
probably should. There are several skills you'll
need to develop which can't be practiced on
a single machine (NIS, NFS, DNS, sendmail or other
mailer, etc).
Good luck!
Slashdot Mirror
I'd also like to add that I was, in fact, referring to my use of root privs on workstations. So *nyah*. 8-)
Secondly, you still haven't eliminated the trust issue, you've just pushed it back a little. Don't forget that there's a whole level of hardware trust involved. I already mentioned taking the system hard disk out for "maintenance" but there are other avenues as well.
Thirdly, you're also assuming that two or more "independent" parties won't actually be acting in collusion. For a large enough payoff, say US $150 Million, would you be willing to bet that the system manager at your investment brokerage couldn't find someone to collaborate with? I wouldn't make that wager.
Even assuming the absence of an all-powerful superuser, there are problems. Someone has to be responsible for installing, maintaining and perhaps upgrading the application that manages the dual-approver system, so there's at least one person who doesn't need any confirmation before setting you up the bomb.
And even if you solve that problem, there's the problem with untrustworthy hardware. Someone somewhere has physical access to the box, which would provide them with the ability to, say, take the disk drive "for maintenance", mount it in their own box, diddle whatever code they want, and return the "fixed" drive to service.
And that brings up the problem of... and then the problem of... not to mention the problem of... it just keeps going. With our current technology, it's literally impossible to eliminate the issue of trust in our computing environments. They say everyone has their price. Scary thought, isn't it?
Yeah, I've seen these in the mall, but I've never been into The GAP. I always thought they were just clothing stores...
Harwood-san wa wakarimasu, neh?
Do I get extra points for a Japanese nick?
This isn't actually as big a shock as it appears, at least not if you've been following grid computing. IBM has already invested heavily in grid services and software. That's what this is aimed at.
They've been known to make this sort of heavy financial commitment to important technologies before (like Linux), so I expect this to be more of the same. In particular, it's good because it means they'll be in the Grid business for quite a while. Also, grids are hard to get right if you're designing them yourself, so having IBM do it for you will probably work out to being a substantial savings, both in time and money.
That is, in fact, a very good reason. Keeping current with the latest Solaris releases is quite a useful thing to do.
I also have another reason that probably won't apply to everyone here. I do freelance writing and a lot of it has to do with information security. When I need to try new tools or techniques, I never want to try them on my real computers if there's even any *chance* they might be dangerous. I use VMWare virtual machines running Linux and Windows. I'm going to be adding Solaris x86 to that mix soon, since virtually every result I'd gather from those systems will apply equally well to the SPARC systems most people have. I'm really looking forward to adding Solaris to my "virtual test lab".
"Here's my computer. I'll be back in 10 minutes. I want my box rooted 10 ways from Sunday. Make me your bitch."
Otherwise, it's was pretty clever. I guess your boss was a bit shocked...
I think a multi-pronged approach is in order.
First, open source project teams should try their best to make sure that their distribution points are secure. I know that no one intentionally distributes code from known-bad servers, but rather than just assuming security in the absence of knowledge to the contrary, I think they should make the security of their servers more of an active part of their project.
Second, they should register PGP keys with the key servers. Popular projects could even sign each other's keys, creating an informal web of trust. For example, the FreeBSD, OpenSSL and OpenSSH teams could maybe sign each others keys. This would help users make sure they don't download false keys from the servers.
Project teams should keep their private keys on read-only media (like a CD-R), and only 2 or 3 trusted members should be allowed to sign distributions. Really large projects could even do key splitting, so that (for example) 3 out of 5 developers are required in order to sign a release.
Of course, the project files should have detached signatures available in the same place that the distribution is. If it's FTP, put the detached signature in the same directory as the tarball. A lot of projects already do this. A pointer to the signature should be included in the project. Preferably, this should be in a standard file, like the $PROJECTROOT/SIGNATURE file, to make it easy to find.
If all these suggestions (or something like them) were followed, then someone who downloaded a package could use an automated tool to check the signature in one easy step. It is almost axiomatic that convenient security procedures get followed far more often than inconvenient ones, so I think automation is an important consideration here. It would add only one easy step, transmuting
configure && make && make install
to
checksig && configure && make && install
Ok, I know a lot of people have already replied, but here's a point that I didn't see anyone
make explicitly yet, though it was left unsaid a couple of times. It's also my favorite answer to the question "Why care about anime?"
The point is this: Animation allows more types of stories to be told within a limited budget. Animation is way cheaper than live action, especially for stories that aren't set in today's world or that require a lot of special effects for whatever reason. This could be sci-fi, like Cowboy Bebop, but also historical. It could be action (explosions and car wrecks cost too much) or romance. It doesn't matter. The lower cost of animation allows more stories (in any genre) to see the light of day.
I'm a huge Cowboy Bebop fan. I've got all the soundtrack CDs, too. I'm disapointed I can't see the NYC premiere. I'd love to meet Yoko Kanno, but oh well.
See you, Space Cowboy...
I agree with various comments already made about how you can't really count on the laptop's configuration itself to keep the students from using email, etc. It's too easy to reinstall an OS without the locked-down configuration, for one thing. If you can't do it at the host level, the network level is an obvious next step.
Just a wild idea, but what about a modified intrusion detection system? Rather than detecting people coming into the network, it could look for anomalous behavior, such as ICQ traffic during class periods. You might not be able to stop it, but you could probably detect it. I think you could write rules for pretty much anything you'd need to detect in Snort, for example.
You're right. You *can* practice them, it's just pretty useless.
During this time, I also helped a friend of mine (who was an English major at the time) learn to use the Unix workstations and the Internet. He parlayed this into a position within the help desk organization and then eventually into the administrator group also. So it's possible to do if you have one person who can give you the first break.
If you're not in a university environment, probably your best bet is to try to get involved in the Linux community somehow, get your name attached to some projects that you can use as partial credentials on your resume. Also, if you're not already running a network of at least a couple of Linux machines at home, you probably should. There are several skills you'll need to develop which can't be practiced on a single machine (NIS, NFS, DNS, sendmail or other mailer, etc). Good luck!