On 2006-10-11 mcr@sandelman.ottawa.on.ca wrote:
> >>>>> "Matthew" == Matthew Orgass <darkstar@city-net.com> writes:
>     Matthew> An alternative would be to let, say, inetd determine this
>     Matthew> even for separate servers and provide a notification
>     Matthew> interface if the server really needs to know what
>     Matthew> interface/address(s) it is listening on.
>
>   That sounds really complicated, but maybe I'm mis-understanding you.

  I have a few related things in mind which I confused a bit above.  It is
complicated and not a ready to use proposal.  I think your solution would
be good in the context of trusting the applications to administer
privilege, but I think that should be avoided.

  IMO the application alone should not determine what ports it can listen
on and that this information should be in a single location since
otherwise it is difficult for the administrator to be certain what
applications are allowed on what address/port combination.  Applications
should not then need to be configured for particular addresses in addition
to this central configuration.

  This should be possible without any changes to applications, however I
think that due to the separation of bind and listen it might appear that
they are listening on more addresses than they really are.

  My further thought is that based on the above a simpler API could be
created where the application does not specify the address or port name at
all, but will use what is configured (a combined bind/listen call).  It
might then also be allowed to change the addresses and ports used while
the server is running (is this already allowed with a wildcard address?).

  I think there are two basic ways to approach privilege: irreversible
privilege lowering or elevating privilege under some circumstances (binary
based or otherwise).  To avoid needing to restart process trees when
privilege changes the privilege conferred sometimes needs to be membership
in a class, but the application then needs to be aware of what can change.
IMO, if the state is detailed (such as multiple address/port bindings) the
application should then if possible avoid needing to care about these
details so that then can be entirely managed in an application-independent
manner.

  Delegating privilege based on the particular resource requested allows
finer grained permissions, but that needs more complex analysis and
potentially user interaction.  IMO, privilege should never raise except by
being passed separately authenticated resources.  However, to accomplish
that with reasonable compatibility I think it is necessary to be able to
establish communication between userland processes based on existing
system calls (which I think should not be too difficult now due to kauth).

  IMO, users should also have the ability to restrict their applications
to a subset of the resources available to the user.  I think this needs
some sort of generic privilege class hierarchy. If this is sufficiently
detailed then the history of privilege can be used for later resource
passing decisions.

  IMO, port privilege for server applications would be a good place to
start a new privilege model.

Matthew Orgass
darkstar@city-net.com