From: Ted Zlatanov <[EMAIL PROTECTED]>
Date: Fri, 02 Jun 2006 10:22:25 -0400
On 1 Jun 2006, [EMAIL PROTECTED] wrote:
> Let me clarify a bit more what I need to do. We want to use $USER
> to verify a valid user before running the program, so this is very
> unlikely go on the web or have a web interface.
You can tie web-based authentication to an external user database
(e.g. LDAP/Active Directory/the PAM stack). It can have its own
authentication database. This is as secure as relying on the Unix
login process, if configured properly. Just run over HTTPS to prevent
snooping.
Good point. Even creating your own htpasswd database should be as good
as LDAP or Active Directory, since the auth DB and software can be
thoroughly protected from users, and probably better than PAM (about
which I've heard bad press, but not attended to the details). And HTTPS
is not necessary if (as discussed earlier) the daemon binds to the
loopback interface -- no network means no snoopers.
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?
It sounds like you're set on writing this in text mode, but I hope the
suggestions help, especially that you should always ask for a password.
Ted
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"?
But this turns out to be academic in this case. Jan said the
following offlist last night:
The access is to an individual course account, and all course staff
have the password to it - no other courses/accounts are involved.
So all that is necessary is for the grade DB to be kept in a directory
with 700 perms owned by this single account.
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 . . ."
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.
-- Bob
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
