Capsicum and connect(2)

Shawn Webb shawn.webb at hardenedbsd.org
Tue Sep 26 22:06:32 UTC 2017


Perhaps. But if the file descriptor is given the CAP_CONNECT capability, I
should be able to call connect(2) on it, right? The manpage for
connect(2) does not state that connect(2) is fully disallowed, even if
CAP_CONNECT is a granted capability.

On Tue, Sep 26, 2017 at 10:02:53PM +0000, Ben Laurie wrote:
> ECAPMODE means the syscall is forbidden, surely?
> 
> On 26 September 2017 at 20:37, Shawn Webb <shawn.webb at hardenedbsd.org> wrote:
> > Hey All,
> >
> > I'm working on applying Capsicum to Tor. I've got a PoC design for how
> > I'm going to do it posted here:
> >
> > https://github.com/lattera/PoCs/tree/master/capsicum_fdpassing
> >
> > Note that the above code might have ugly spots. It's mostly just a brain
> > dump.
> >
> > Essentially, the child process creates the socket and passes the
> > socket's file descriptor back to the parent. The socket file descriptor
> > has the capabilities sets already applied to it before it goes back to
> > the parent. The socket creation and file descriptor passing seems to
> > work well.
> >
> > However, what isn't working is calling connect(2) on the socket file
> > descriptor in the parent. errno gets set to ECAPMODE. This is puzzling
> > to me since CAP_CONNECT is set on the descriptor.
> >
> > Any help would be appreciated.
> >
> > Thanks,
> >
> > --
> > Shawn Webb
> > Cofounder and Security Engineer
> > HardenedBSD
> >
> > GPG Key ID:          0x6A84658F52456EEE
> > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20170926/4377fea6/attachment.sig>


More information about the freebsd-security mailing list