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 -------------- 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/610f361a/attachment.sig>
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
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>
On Tue, Sep 26, 2017 at 07:37:53PM +0000, Shawn Webb 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.It turns out that connect(2) isn't annotated with SYF_CAPENABLED, even though the CAP_CONNECT capability exists. I've fixed it in HardenedBSD: https://github.com/HardenedBSD/hardenedBSD/commit/1b1b6b8f1ec1fbbefc5de82f0b15bb470beda370 I've also filed a bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222632 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: capsicum_connect_r01.patch Type: text/x-diff Size: 1186 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20170926/78ae5e88/attachment.patch> -------------- 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/78ae5e88/attachment.sig>