I can imagine pledge(2) becoming very complex if individual ports are
blocked. It is not just the syscall, it's also the code in the
kernel. From what I can gather, pledge is really to restrict processes
to a subset of functions available, rather than restricting each
individual argument, unless there are exceptional reasons for doing so.
However, out of curiosity I've been tinkering with PF rules.
Ruleset:
block drop all
pass in proto tcp from any to any port 65535 user test2
Then running as user "test" (NOT test2):
$ nc -l 65535
Note nc stays there, probably opened the socket successfully.
Even with "block reset all" in PF rules, nc does this.
It would be nice if the "reset" keyword tells the kernel to return
EACCES when bind(2) is called on a port blocked by PF rules for a
particular user.
Such a facility would even be better than "privileged ports" as many
applications which listen on these ports cannot even be blocked
reliably with PF rules, as per pf.conf(5):
The user and group arguments refer to the effective (as
opposed to the real) IDs, in case the socket is created by
a setuid/setgid process. User and group IDs are stored
when a socket is created; when a process creates a
listening socket as root (for instance, by binding to a
privileged port) and subsequently changes to another user
ID (to drop privileges), the credentials will remain root.
On Wed, 26 Apr 2017 11:19:20 +0000
Luke Small <[email protected]> wrote:
> I'm not saying to alter pledge necessarily, maybe make new system call
> like pledge. There aren't any per-process pf rules that are applied.
> When a socket connects to a remote or local server and pf makes a
> state, it has the originating randomized port. Pf rules can be made
> that target those randomized port numbers, but maybe there could be a
> more elegant way like intervening in connect() and bind() calls.
>
> >you can have rules to filter by user >for both
> >incoming and outgoing connections, see
> >http://man=2Eopenbsd=2Eorg/OpenBSD->6=2E1/pf=2Econf=2E5#user
>
> >I don't think there's too much gain in >adding
> >support for this kinda thing in pledge >but
> >that's for the devs to decide=2E=20
