IP_NONLOCALOK improvements.

[Julian Elischer]

Pawel Jakub Dawidek wrote:
>
>>> All in all I went with rename to make at least similar to OpenBSD's
>>> option. I left it as IPPROTO_IP option: IP_BINDANY.
>> well, ok, a rose by any other name would smell as sweet.
>> As I  said I was not aware of the OpenBSD code, but I don't like
>> their choice of name as it doesn't really describe what it does.
> 
> I changed the name just to be more similar to OpenBSD's (and BSD/OS') so
> one can more easly find it by grepping. I'm really fine with any name.
> 
>>> I added new privilege - PRIV_NETINET_BINDANY, because we do have to
>>> check for privilege before allowing to use it.

are we sure we want to make a whole PRIV just for this function?

>> I am not sure about this. if a system has this enabled then I presume 
>> it is a special system and not a generally available time-sharing system.
>>
>> How do you allow a process to have this privilege? are you forcing 
>> them to be root for now?
> 
> Our current privilege model is that we have fine-grained privileges in
> the kernel, but those are not _yet_ exposed to userland. All privileges
> defined in sys/priv.h are available for unjailed root and some (take a
> look at prison_priv_check() function) for jailed root.

when we have vimage, this may be required in some vimages and not 
others..  the priv should be inherrited but gated on the new
jail.. in other words, when yo create a child jail, it can do it if:
1/ the parent can do it
AND
2/ the parent allows the child to do it.

> 
> Today this new privilege will only be available for unjailed root.
> 
> At some point we will grow possibility to selectively add/remove
> privileges just like Solaris, but we can't do that now.
> 
>>> I removed kernel option to enable it, I see to reason not to have it in
>>> GENERIC.
>> Because it adds complexity and because some people do not want it even 
>> possible.
>> You are eneabling NON-standard, (in fact "Standard-ignoring")
>> behaviour.
>>
>>
>>> I also removed sysctl to enable it - we have privilege for limiting its 
>>> use.
>> I disagree very strongly about this one. I would liek to
>> 1/ have to explicitly compile in thi snon standard behaviour and
>>
>> 2/ turn it on
>>
>> before we start doing this.
>>
>>
>> I know how useful this is to have, (from my own experience)
>> but feel strongly that this is pretty bad behaviour for most systems
>> and can facilitate all sorts security worries.
> 
> Well, this is behaviour is similar to adding an IP address to an
> interface and binding to that address. There is even no securelevel that
> denies modifing interfaces, so in my opinion if one needs to explicitly
> ask for this to be enabled for a socket and one needs a special
> privilege to do it, it should be enough protection to make user's live a
> bit less complex by not requiring kernel recompilation and sysctl
> modification.
> 
> I'm not sure if this was on purpose, but currently even unprivileged
> user can use this functionality if the sysctl is on, which I find hard
> to accept. Having this always enabled and requiring a privilege is IMHO
> more secure than allowing anyone to use it once the sysctl is on.
> But again, combining the two (privilege and sysctl) is redundant IMHO.

it was on purpose as it was assumed, as I said, that anyone compiling
it in would be creating a special "appliance" kernel and be fully
in charge of the machine.

> 
> If it doesn't convince you and I also don't feel convinced we need to
> wait for more votes:)

I can live with having it there by default in GENERIC, but I'm
not sure I don't still want to be able to remove it..
the sysctl could go , but I felt I wanted a way for the admin
to disble it on a system if it shared a kernel with other
systems that need it.


i.e. if it's in GENERIC, then I think the admin should be able to stop 
it from being available.



>