On 2 Jun 2006, [EMAIL PROTECTED] wrote: > The key is to let somebody else do as much of the authentication > implementation as possible, as it's tricky and time-consuming to get > right. > > > The Unix login process can be subverted by sudo (not to mention that > > $USER can be set to anything, as others pointed out). You should > > always request a password if security is a concern. Don't trust the > > UID or environment . . . > > I don't understand. The environment is certainly untrustworthy, but how > (in the absence of an OS bug) would an attacker change the effective UID > without login credentials?
There are many more ways to attack a system from the inside than from the outside. For example, you know the exact OS version, library versions, file locations, etc. If an attacker has sudo, forget it, effective UID can be anything. > But what are you going to do with that password? Compare it to some > database and then die if it fails? That is sound for CGI, but not for a > perl script that is run from the shell. What if an attacker edits the > script and changes the "die" to "warn"? Of course, if the user can edit the script, he can do anything with it, but I would hope the script is not setuid root (or accessible via sudo). If that's not the case, the user can only make the script do the things he could do from the command line anyway. > But this turns out to be academic in this case. Well, it's an interesting discussion even if it's not directly useful to the OP. I hope someone else finds it useful. > Which brings to mind another useful thing: If the old versions of > the grades file (call it "grades.csv") were kept in numbered backups > (e.g. "grades.csv.1", "grades.csv.2", etc.), it might help in case of > bugs, or if a TA ever says, "I really screwed it up . . ." Better yet, put it under a VCS (CVS, Subversion, etc.) and your history is ready. > Which in turn points out one of the drawbacks of using a shared > account: If somebody else finds a problem, you won't know who to > contact about what went wrong. Even worse, IMHO, is the fact that > people are much more casual with shared accounts, particularly about > guarding the password. To be honest, I've set up a few of those at our > site, but only for very low-privilege purposes. And, since we were > discussing security, I felt I should bring it up. Agreed. In fact, after hearing more about the problem, it sounds like a wiki may be useful. With per-user passwords and built-in versioning (with knowledge of who edited when), it may be sufficient. Table editing in wikis is pretty simple, see for example http://meta.wikimedia.org/wiki/Help:Table Ted _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
