At 14:05 2002-02-14 +0000, Edward Wildgoose wrote:
I have a some Procmail scripts that are working quite well,
but I have
some variables that I would like the users to be able to adjust, eg
forwarding address, pager number.
The users all have local accounts, but can't log in to them.
They have
web, mail, pop and IMAP access only.
Then uh, perhaps use an https interface?
Great, I count that under the web access that they will have.
My first thoughts are to build a quick web interface to
allow users to
change these settings, but I think that this raises security
problems, ie
how does the web server write to a file in the users home directory.
Don't - instead, write to a file (or DB) which a user process
can access.
Yep, sounds good. Basically the idea outlined below I think - different spin
though?
One thought might be to put the variables into seperate
files that are
writable by the web server, and the .procmailrc has readonly access,
checks the value in the file for sanity and uses that value
in the rest of
the script (eg forwarding address for e-mail). However,
there must be a
neater way to do this and this still leaves some security holes.
If it comes to it, keep in mind that you can do things from
/etc/procmailrc
which you cannot from within the user's own .procmailrc
Now this has some potential! Good thinking batman, saves the SUID
I have seen this done using a small C program which runs
SUID, does a
chmod and chgroup to the correct user and then writes the
data. Is this a
good idea..?
I'd say NO - it becomes yet another program you need to be
concerned about
exploits in because it starts as SUID root.
Another thought is that I could use procmail itself, eg send
an encoded
file to the user with details in the body. This would get
spotted by the
.procmailrc and update the local variables and then ditch the email
without delivering... Is there some way to make this safe
without the
risk of outsiders sending in mail to the users with commands
in the body...
Require users to PGP sign their commandfiles and have the
scripts check the
signature?
I was thinking much simpler than this. The users would use the web interface,
which would send the user a message that gets eaten by their procmail. The user
doesn't write the message. In fact the question is really how to stop anyone
external to the local machine sending mail in that would get processed in the
same way, ie procmail would only respect commands in an email which obviously
came from the web interface.
This would be the way to get the commands from webserver account to user
account. Any merits here? Sounds too complicated and fragile I think...
(Clever though)
In all this we must assume non-technically literate users
with a small
patience threshold.
Then IMAP and PGP signing aren't going to be the solution,
because those
demand at least a minimal tech IQ. A web-based interface can
The IMAP idea was that the web interface would use IMAP to drop the data into
the users interface (just log 'em into IMAP as you log into the web interface).
Great idea? Possible...?
If I were stuck with this weird need, I'd have the web
These users are on a small boat in the middle of an ocean and pay $1.50 a
minute to dial-up to the web at 2400 baud ... (possibly while being thrown
around in a gale, holding the sat-phone up with one hand to get better
reception and operating their laptop with the other). Getting support is
expensive, just receiving email is expensive..
Unusual need perhaps. Wierd, I don't think so. :-)
interface stuff
variables into an SQL database, along with the (https)
authenticated userid
(which is used as the key field). Procmail can run a program which
accesses the db using a READ-ONLY db account (using the
current user, not a
passed argument for the db key), thus an exploit of that
perl/c/whatever
program wouldn't lead to being able to CHANGE other user's
accounts. This
prog could then create an includerc file for this user which defines
multiple variables:
:0:PROCVARS$LOCKEXT
* ! ? variablemaker $HOME/procvars.rc
{
INCLUDERC=$HOME/procvars.rc
}
The variablemaker program would do the db lookup and GENERATE the
procvars.rc file, which, if it successfully completes (zero
return value),
will allow procmail to read that procvars file.
Great idea. I would like to explore this option some more. Perhaps we can
drop privs early on and do the read in the users privs, this should make an
exploit much harder.
I come from an MS world, so not sure what the easiest way to write a DB
interface would be. Does anyone have some sample code using script, etc.
The thought occurs that a plain text file is just as secure for all practical
purposes? eg web process writes to a file with the user's login name (say),
which is owned by the web process and group read privs everyone else. Or
slightly more secure would be group read that user only.
The .procmailrc file can then go straight into that file on every invocation
and pick out the current values of the variable. I guess that we have "per
email" overhead of doing the check that the contents are reasonable and have
not been "poisoned" by someone seeking to subvert my users procmailrc. Even
this could be solved by copying the details locally + checking if changed and
therefore assuming local version is safe otherwise.
From a performance point of view, would it be significantly better to get the
"copy local" process to create a whole rc file with params filled in, rather
than an rc file which reads a couple of external files and parses them for
contents to fill local variables? It would be desirable to split things in
two so that I can keep a generic .procmailrc file which is added to users
directories automatically and the variables are just "included" at runtime.
(Reminder: the variables are things like pager number, max message length that
they want to receive, etc)
Could I just write the rc file in the following format and include it with
INCLUDERC=./vars.rc
$PAGER="123123123(_at_)msg(_dot_)iridium(_dot_)com"
$MaxLen=4000
Note that if the script sees that "I've already updated"
(say, the db field
has a date, and variablemaker checks that the rc file isn't
newer, or it
actually reads and compares the variables), it doesn't
actually have to
re-make the procvars.rc file each time, so you don't get hit with the
additional overhead of file writing. As long as there isn't
an _error_,
it'd still return a sucess code.
Locking ensures that you're not updating the file while it's
being read by
another procmail process.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer:
<http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy
from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail