Date: Mon, 18 Nov 1996 10:45:39 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: freebsd-security@FreeBSD.org Subject: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2). Message-ID: <199611181845.KAA15940@salsa.gv.ssi1.com> In-Reply-To: Poul-Henning Kamp <phk@critter.tfs.com> "Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2)." (Nov 18, 8:30am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 18, 8:30am, Poul-Henning Kamp wrote: } Subject: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2). } What we REALLY need, is a way for root, to hand out certain priviledges. } } Imagine this: } } sysctl -w net.inet.tcp.uidforport.25=`id -ur smtp` } sysctl -w net.inet.tcp.uidforport.20=`id -ur ftp` } sysctl -w net.inet.tcp.uidforport.21=`id -ur ftp` } sysctl -w net.inet.tcp.uidforport.119=`id -ur nntp` } } This means that users with UID smtp can bind to socket 25 (aka smtp), } and so on. Now sendmail NEVER needs to be root. I was thinking more along the lines of chroot(), but for port numbers. Root could mark a process and it's decendents as having access to port 25, and other processes and their decendents as never having access to port 25, even if they are root. I'd have two independent sets of limits, one for run-of-the-mill processes and one for "privileged" processes. Of course, the average processes wouldn't be able to access anything the "privileged" ones couldn't. Of course, our schemes could be combined and access granted to the intersection of the two sets. --- Truck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611181845.KAA15940>