Re: pledge for sockets

On Sun, 30 Apr 2017 00:29:01 +1000 wrote: ... > 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. Mistake

Re: pledge for sockets

I think I found a way to configure the redis.conf to connect to redis through a unix socket instead, which will seem to clean up some stuff. If I need to later, I could probably spawn a process to relay commands from a unix socket to an inet socket that is limited to a single port through a

Re: pledge for sockets

I have a program that I believe needs inet to talk to a database(libhiredis). I do pass file descriptors to it. I don't suppose making it run as a different user and limiting the pf config would really lock it down without losing functionality. Maybe I'm too paranoid. On Sat, Apr 29, 2017 at 9:51

Re: pledge for sockets

> 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

Re: pledge for sockets

> Am 26.04.2017 um 13:38 schrieb Luke Small : > > Pledge will presumably have per process (including fork()ed process) **path > limitations on rpath rpath and wpath calls, why not limitations on inet and > unix? We usually want to isolate our network speakers from the

Re: pledge for sockets

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

Re: pledge for sockets?

Luke Small wrote: > Would it be a good idea to make a pledge like call that limits a process > from connecting to ports and/or hosts? Maybe it could be done in way that > the kernel is made aware of the limitations like in a pledge call and while > the process is alive, the kernel spawns pf rules

Re: pledge for sockets

I guess that representing something like "block out user daemon_id" and "pass out quick from any to specific_host port specific_port user daemon_id" in terms of pledge() parameters would make it rather unwieldy, if you want your fooDB to only be able to make outward connections to the designated

Re: pledge for sockets

Pledge will presumably have per process (including fork()ed process) **path limitations on rpath rpath and wpath calls, why not limitations on inet and unix? On Wed, Apr 26, 2017 at 6:26 AM Janne Johansson wrote: > 2017-04-26 13:19 GMT+02:00 Luke Small

Re: pledge for sockets

2017-04-26 13:19 GMT+02:00 Luke Small : > 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. If your daemon has a specific user, you can make such rules in PF. The goal you stated

Re: pledge for sockets

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

Re: pledge for sockets?

Hi Luke, you can have rules to filter by user for both incoming and outgoing connections, see http://man.openbsd.org/OpenBSD-6.1/pf.conf.5#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. Regards, Florian Am 26.

Re: pledge for sockets?

That sounds like what pf can do for stuff running on the local machine, based on userid of the process opening the sockets. At least if your daemons all run as separate users. 2017-04-26 10:09 GMT+02:00 Luke Small : > Would it be a good idea to make a pledge like call that

pledge for sockets?

Would it be a good idea to make a pledge like call that limits a process from connecting to ports and/or hosts? Maybe it could be done in way that the kernel is made aware of the limitations like in a pledge call and while the process is alive, the kernel spawns pf rules based upon the socket