Subject: Re: i386 IO access and chroot()
To: None <email@example.com>
From: Michael Richardson <firstname.lastname@example.org>
Date: 07/14/2001 23:36:28
>>>>> "Greg" == Greg A Woods <email@example.com> writes:
Greg> [ On Saturday, July 14, 2001 at 21:19:49 (-0400), Michael
Greg> Richardson wrote: ]
>> Subject: Re: i386 IO access and chroot()
>> 4. bind < 1024 5. network operations, period
Greg> I don't yet fully understand the implications, but I'm very leary
Greg> about allowing non-root users to do anything like this under any
I want to restrict *root* in a *jail* from binding less than 1024.
Greg> Take for example SSH. If you get right down to the brass tacks,
Greg> SSH requires you to trust the OS and hardware at each end of the
Greg> connection (which of course implies that you can trust them to have
Greg> done the authentication, but that's a separate issue). As I
Greg> understand the Unix security model in combination with the SSH
Greg> protocol this means that SSH must run as root on both ends and the
Greg> initial use of a TCP port less than 1024 is key to the web of trust
SSH can emulate "rhost" <1024 stuff if you insist. That is not the default.
You can permit RhostRSA to use RSA to authenticate hosts. That depends upon
access to /etc/ssh_host_key, which is why ssh client is often setuid. This
also is often not the default. (although setuid ssh has been the default in
Most use of ssh does not require any of this.
Greg> By adding some kind of access control mechanism that allows
Greg> non-root users to do "trusted" network operations you are
Greg> shouldering responsibilities onto non-root users and I'm not so
Greg> sure you should be.
My goal is further restricting even root.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] firstname.lastname@example.org http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [