Assigning the PRIV_NETINET_BINDANY privilege required for setsockopt(IP_BINDANY)

Robert N. M. Watson rwatson at
Thu Jan 12 09:44:53 UTC 2012

On 12 Jan 2012, at 06:03, Adrian Chadd wrote:

> On 11 January 2012 15:26, Gerald McNulty <gmnt99 at> wrote:
>> Using IP_BINDANY to facilitate transparent proxying works as specified.
>> According the ip(4) man page and sys/netinet/ip_output.c, the
>> PRIV_NETINET_BINDANY privilege is required in order to make a setsockopt()
>> call with IP_BINDANY.
>> I would like to use this in an app that does not run as uid 0. Is it
>> possible to assign the PRIV_NETINET_BINDANY privilege to a specific uid or
>> process or can this mechanism only be used in jails to reduce root
>> privileges further?
> I'm not sure if the relevant bits of MAC have been committed. Robert?

Hi Adrian, Gerald:

Currently there isn't a general-purpose privilege management policy in FreeBSD. The MAC Framework supports specialised policies that modify OS notions of privilege -- for example, the Biba policy does this, but it's not what you're looking for. We have vague intent to do two things:

(1) Add a role-based privilege model, allowing privileges to be assigned to users as already possible in some other systems (such as Solaris)
(2) Allow masks of privileges available to root (etc) in jails to be explicitly managed, rather than relying on the hard-coded privilege list currently in the Jail implementation

The groundwork was laid for this in FreeBSD 7.0 with the itemisation of available privileges, but a significant amount of further work remains to be done. Despite the best intentions, it happened neither for 8.0 nor 9.0. Some downstream consumers of FreeBSD use specialised MAC policies to delegate rights to non-root users, but I'm not aware of a policy implementation currently appropriate for upstreaming to us.

I'd very much like to see this happen for 10.0, perhaps even with a merge to 9.x, but currently there isn't an owner for this project. It involves quite a bit of subtlety and care -- getting it wrong has the potential to make a system more, rather than less, vulnerable.


More information about the freebsd-hackers mailing list