[tpop3d-discuss] an update
Chris Lightfoot
chris at ex-parrot.com
Sat, 9 Nov 2002 13:51:33 +0000
On Fri, Nov 08, 2002 at 02:00:43PM -0700, Ben Schumacher wrote:
> Hey Chris-
>
> Chris Lightfoot wrote:
> >>>I've got about half way through reimplementing the I/O
> >>>layer of tpop3d to support TCP and TLS in a reasonably
> >>>clean fashion. Hopefully this weekend I'll be able to get
> >>>something actually up and running, but I'm rather busy at
> >>>the moment, so this isn't guaranteed....
> >>
> >>Looking forward to it :) How's the progress?
> >
> >
> >Slow. I've been bogged down in other things. Unfortunately
> >the difference between the TLS and TCP semantics has
> >driven me to alter fundamentally the way the core network
> >stuff works.
>
> I've been following your changes in the anonymous CVS, and I'm still
> confused as to why you decided it wasn't necessary to split out the TLS
> stuff from the main process.
Ah, in the brave new world of free software, everyone's
mistakes are recorded forever in CVS.... :)
> I'm still concerned whether there are
> security implications, as the private key will be in memory of a process
> owned by the user after authentication. Did I miss something? I might
> need to go back and look at the archives, but I wasn't certain that
> anyway around this had been figured out.
I believe this this is fine, because on typical systems,
ptrace can't be used to attached to programs which are
setuid. As an example, run this program
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <pwd.h>
int main(void) {
struct passwd *p;
p = getpwnam("chris"); /* XXX */
if (!p) {
perror("getpwnam");
return -1;
} else if (setgid(p->pw_gid) == -1) {
perror("setgid");
return -1;
} else if (setuid(p->pw_uid) == -1) {
perror("setuid");
return -1;
} else {
uid_t ru, eu, su;
gid_t rg, eg, sg;
getresuid(&ru, &eu, &su);
getresgid(&rg, &eg, &sg);
printf("waiting; PID is %d...\n", (int)getpid());
printf("R/E/S uid %d/%d/%d\n", (int)ru, (int)eu, (int)su);
printf("R/E/S gid %d/%d/%d\n", (int)rg, (int)eg, (int)sg);
while (1) pause();
}
}
as root, and try attaching to it with gdb as the setuid
user -- you won't (shouldn't...) be able to. I think this
means that it's OK to retain the private key in memory. I
don't, however, understand exactly what the semantics of
this are. In Linux, the game appears to be that a process
which calls setuid to change its user ID is marked
non-dumpable (current->mm->dumpable = 0) and this is then
tested when ptrace is called. I guess other systems do
something similar.
--
``WATCH A REAL WAR from a glass-bottomed helicopter...
More Realistic than DVD.'' (from `TV Go Home')