Date: Tue, 08 May 2001 08:20:24 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "William E. Baxter" <web@superscript.com> Cc: hackers@FreeBSD.ORG Subject: Re: Getting peer credentials & link management & overpartitioning Message-ID: <3AF80EB8.FBCFB097@mindspring.com> References: <20010504230540.00BEE3E0B@bazooka.unixfreak.org> <20010504170738.U18676@fw.wintelcom.net> <20010504214702.A29392@zeus.superscript.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"William E. Baxter" wrote: [ ... "Subject:" ... ] > And as Alfred points out, perhaps unintentionally, the > information should be passed at connect(), because the > client process may exit before accept() returns. Many > simple servers require credentials and nothing more. In > such cases, there is no reason for the client to wait > until accept() returns. I think that the most important issue to address is the one of intentional interposition, without a tunnel. Specifically, it is extremely useful to consider a link management device for a dial-on-demand or on-demand-VPN type system, where you are hooking to what is in effect, a circuit switched network. The historical problem is the glue code. Really, you want to be able to have a daemon that opens a /dev/link (or other device), and if the device is open, all attempts to open a socket may be administratively denied, based on the credential of the requester. This permits a centrally administered link management policy, without having to grow warts on every program in the ports directory in order to have common link control. The biggest intrusion is the ability to fail calls to things like "connect(2)" with "EADMIN" or a similar administrative denial error. I am _completely_ convinced that the most glaring architectural error in the design of the Whistle InterJet was the lack of a centrally administered link management policy. Lack of such a policy led to wrapper programs and intrusions (sometimes by adverse code) into standard network programs, for things like sendmail and other porgrams that needed to run at periodic intervals, but for which a "non-business hours" policy needed to enforce that the link stay down without explicit demand on behalf of a real human. If there were only _one_ thing I could go back and change to save a butt-load of useless meetings and a huge amount of support overhead, it would be a hard call, but I'd probably have to pick "implement centralized link management". > My ucspi-ipc package provides a framework for turning filters > into servers based on getpeereid(): > > http://www.superscript.com/ucspi-ipc/intro.html > > A collection of simple servers, some of which perform > operations normally delegated to setuid programs, is > available at: > > http://www.superscript.com/ipctools/intro.html The primary reason for SUID is to get priviledged ports, or to enable things like "chroot(2)", since it takes priviledge to relinquish priviledge (ironic, eh?). SCO had a nice approach to this, where it could flag certain programs as having additional, specific rights (as opposed to "all-or-nothing"). Specifically, the most useful one was the ability to change to another (non-root) UID... once. The second most useful was the ability to get a priviledged port. I really can't see how, say, telnetd would benefit from the design you put forth (actually, it'd be much better off as a pty-using netgraph node, IMO). I think that the general utility of the idea of partitioning is useful only for trivial programs (e.g. qmail or DJBDNS), which are, by design, already partitioned, and so, also by design, have some serious limitations. > If you think that getpeereid(), or sufficient basis for it, > should appear in future versions of *BSD, please tell the > implementors. My implementation remains theirs for the asking. FWIW, I think it should, if only for the link managemenet case. I certainly think that, if adopted, it should be a (3) wrapper in the library for fcntl(2); personally, I would have it stick with a pure fcntl(2) interface, rather than introducing yet another abstraction. I also think that the entire system as it currently exists is overkill; I would like to see integration of image priviledges instead, most likely through the POSIX ACL mechanisms which have been recently adopted by FreeBSD , Linux, and others. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AF80EB8.FBCFB097>