Subject: Re: Addition to force open to open only regular files
To: NetBSD Kernel Technical Discussion List <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 11/30/2000 15:42:56
[ On Saturday, November 25, 2000 at 11:10:48 (-0500), Greg Hudson wrote: ]
> Subject: Re: Addition to force open to open only regular files
> When I pointed out that you could simply chmod /bin/sh setuid and get
> your root shell anyway, he said, "Oh, right, I forgot! We also have
> to turn off the ability to set the setuid bit using the saved ID."
Anyone familiar with the current restrictions on what can and cannot be
done with files that have set-ID bits should have assumed this would be
a necessary restriction of the "enhanced" open_as() too....
> I'm sure I could point out that such a program could get a root shell
> by creating a root crontab entry to chmod u+s /bin/sh in the very near
> future, and he'd come up with same piece of duct tape for that, too.
> And so on. If you have root on the local filesystem, you'll have root
> on the machine in a very small number of steps, complicated Rebus
> contraptions to the contrary notwithstanding.
Yeah of course. Note that I didn't claim there were no such exploits,
just that the ones that remained would be within the limits of a good
intrusion detection system to prevent.
In this case you'd probably need to ensure that the system immutable
flag was set on /etc/crontab and /var/cron/tabs/root or that some other
mechanism were in place to audit changes to such files before cron had a
chance to act on them.
That's why I said "if the risks are deemed acceptable"....
From my view these risks seem much lower than the current seteuid()
risks and thus I propose that even the "enhanced" open_as() is the best
solution to the requirements that would remain when seteuid() is
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>