On Tue, May 01, 2001 at 11:25:49AM +0100, Tim Haynes wrote: > > Andres Salomon <[EMAIL PROTECTED]> writes: > > > Perhaps I'm misunderstanding your proposition, but how is this different > > than, say, having inetd listen on ports below 1024, and then > > forking/changing to a different user once a connection is made to the > > port? > > The current method you describe was vulnerable to bugs concerning setuid(), > as per the 2.2.15->16 bug found by sendmail - having come from root and > called stuid() to become someone else, it was still possible to return to > being root, at which point you have a root daemon running on a port: Bad.
Good point, but from what I understand of this bug (disclaimer: I haven't looked into it that much), it was a mixture of dropping privs in setuid() and capabilities. What's to stop something similar from popping up in code dealing w/ capabilities alone? The fact that a process was coming from root was only a small part of the equation, if I understand correctly. > > If you do it via capabilities in the first place, you never need to have > *been* root in order to bind to the low port. OTOH, by originating from root, you're assured of proper privledges. If you can obtain root (either w/ a valid login, a setuid bit, controlling the execution of another process.. whatever), the system assumes you have the authority to open ports below 1024, and potentially use them to trick other hosts (why bother with man-in-the-middle attacks when you can simply be the man-at-the-other-end?). If the proposal did something that limited a uid 0 process' ability to; for example, restricting it to _only_ listen on a port; I would be fine w/ that. However, this proposal heightens privledges from a normal user (executing a "special" binary) to one w/ more power. Kernel and security bugs (as well as admin/distribution default foolishness) aside, this means that: a) If I happen to be a random user on the system, I can start up a daemon that the admin has stopped for whatever reason (security hole, bug, annoyance). Not only this, but I can start it w/ whatever args I happen to feel like.. `/usr/bin/imaginary-daemon --log-to=~eviluser/log --ignore-grant`. b) The kernel doesn't care about executable types. If it's told that /usr/bin/sshd should be given the capabilities to open a port, it could care less (barring binmisc_fmt) about whether that sshd file is an ELF binary, a symlink, or a shell script (fun w/ IFS). c) Complexity and security don't mix. What would be done in cases of chroots (relative file paths, whee)? What about upgrades? /usr/bin/sshd moving to /usr/local/bin/sshd (the admin has no patience to wait for the latest sshd to get into stable ;) would cause quite a few problems, for example. Mount-points? NFS? Your model of trust is now dependant upon the filesystem. Filesystems were not designed for that sort of thing. This would add some nasty complexities.. > > (This is only half a solution, though: you're preventing them exploiting > root by changing to use capabilities; what if they're out to exploit > capabilities instead of merely `get root'? Still, it'd buy us some time...) > > ~Tim > -- > Newton and Adam, lost and found, |[EMAIL PROTECTED] > The apple must fall to the ground |http://spodzone.org.uk/ > If you're going to grant capabilities to a process (or user), you must first have a rock-solid authentication method with which to make sure they/it deserve that capability. Path/filenames are not a decent authentication method. Uid isn't, either (as I keep telling friends who use sudo w/ NOPASSWD. ugh). Traditional root is gained through the use of a password; while there are many flaws w/ this method, it's still better than relying IP, uid, name, or any other natural attribute a process/connection/whatever may have. sudo does this well by relying on uid, the uid's password, command, and arg.. Ugh, sun's out, bedtime.. -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED]
