Re: unowned processes and who controls them (was: Re: passwd entry for uid -1

[nisse@lysator.liu.se (Niels Möller)]

Oystein Viggen <oysteivi@tihlde.org> writes:

> Would opening the port in the beginning of main() before doing something
> like rmauth(getpid()) count as a better way?

Perhaps. To me it seems somewhat cleaner to have the wrapper script
setup the proper environment, but it's a question of taste, I guess.

> It seems to me, though, that the changes needed to make an already
> existing program use this could be quite intrusive?

I don't know. I would expect the code to create a socket and bind it
to port 20 to be isolated to one or two functions, but I haven't read
nor written any real ftp daemon.

> In comparison, I have here a patch for ntpd that:
> 
> 1. changes UID from root to ntp keeping all privileges
> 2. drops all privileges except the one for opening low ports and the
>    one for setting system time.
> 3. runs the rest of the program perfectly, and completely unmodified.

I don't quite like capabilities as done by linux. For a start, each
added capability-bit adds complexity and potential bugs to the kernel.

And they're not very flexible compared to using ports to represent
capabilities: if you happen to need some new specialized capability
(say, editing a certain record in the utmp file), it would be a lot
easier to write a new server to implement the capability than to hack a
new capability bit into the kernel.

(For utmp, it would make some sense to me to have the port to the
controlling tty include the capability to modify the relevant utmp
records, putting the utmp stuff into the term server, but I don't
really know those corners of unix).

> With your proposed solution, I figure you would need to change all the
> places in the file that are doing something privileged from using their
> current function calls to sending commands through the pre-opened
> fd/port. (changes in glibc could beautify this _very_ much in the actual
> program, though.)

I hadn't thought about glibc hack. Cute idea. It would make the common
cases easier to use, while keeping the powerful port-based
implementation for use when you need something special.

For the "bind-port-X" capability example, you would take the following
steps:

  1. Start the capability service, and get a port to it.

  2. Set some environment variable to tell glibc to try the special
     port if the normal way of doing bind fails.

  3. Drop the ports/uids etc that normal processes use for that
     operation.

  4. Start the *completely unmodified* daemon binary.

/Niels