FS#30541 - [openssh] enable --with-sandbox=seccomp_filter

Attached to Project: Arch Linux
Opened by c (c) - Wednesday, 04 July 2012, 16:55 GMT
Last edited by Gaetan Bisson (vesath) - Wednesday, 01 August 2012, 07:52 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
enable seccomp_filter sandboxing

Additional info:
build configure openssh --with-sandbox=seccomp_filter to make use
of seccomp. seccomp is available in the default kernel package.


Steps to reproduce:
This task depends upon

Closed by  Gaetan Bisson (vesath)
Wednesday, 01 August 2012, 07:52 GMT
Reason for closing:  Deferred
Comment by Dave Reisner (falconindy) - Wednesday, 04 July 2012, 17:10 GMT
Benefits are...?

drawbacks might be...?

documentation about such option is...?
Comment by c (c) - Wednesday, 04 July 2012, 17:29 GMT
Benefits are sandboxing for security.

Cannot think of drawbacks as openssh is 6.0 and the kernel supports it.
It doesn't require patches to either.

http://scarybeastsecurity.blogspot.com/2012/04/vsftpd-300-and-seccomp-filter.html
http://hg.mindrot.org/openssh/rev/f40779d28db5
Comment by c (c) - Wednesday, 04 July 2012, 17:33 GMT Comment by Dave Reisner (falconindy) - Wednesday, 04 July 2012, 17:58 GMT
> http://src.chromium.org/viewvc/chrome/trunk/src/content/common/sandbox_init_linux.cc?view=markup
Yup. Chromium has it because they wrote the userland implementation of what's being pushed into the kernel.

> Cannot think of drawbacks as openssh is 6.0 and the kernel supports it.
Except that it _hasnt_ landed in a mainline kernel yet. openssh doesn't even get past configure with this flag.

Drawback: you won't be able to use ssh with linux-lts even a month+ from now when 3.5 is in core?
Comment by c (c) - Wednesday, 04 July 2012, 18:14 GMT
You're right. Have to wait for linux-3.5 to get PR_SET_NO_NEW_PRIVS.
3.5 should be around the corner. Can we tag the ticket for action linked to linux-3.5 packaging?
Comment by Dave Reisner (falconindy) - Wednesday, 04 July 2012, 18:31 GMT
And what about people using linux-lts which is still 3.0?
Comment by c (c) - Wednesday, 04 July 2012, 20:44 GMT
Once 3.5 is out it should be tested whether sshd built with seccomp_filter runs without the sandbox on older kernels.
If it doesnt a good option may be packaging openssh-seccomp because the security benefit is worth it.
Comment by c (c) - Wednesday, 04 July 2012, 21:08 GMT
It seems to also support other sandboxing options. That could possibly run on older kernels.
Comment by Gaetan Bisson (vesath) - Wednesday, 04 July 2012, 23:14 GMT
Exactly. OpenSSH supports several sandboxes and the one ./configure currently autoselects for Linux is rlimit. (Did you enable "UsePrivilegeSeparation sandbox" in your sshd_config?) For now, I see no gain to force seccomp instead, but feel free to use ABS to maintain your own openssh-seccomp, or to reopen this bug report when linux-lts has the required flags.
Comment by c (c) - Wednesday, 01 August 2012, 07:50 GMT
  • Field changed: Percent Complete (100% → 0%)
openssh HEAD has support for rlimit fallback.
http://marc.info/?l=openssh-unix-dev&m=134330495126295&w=2
linux-api-headers 3.5 is required for build but according to the openssh maintainer with that patch applied (part of next release) openssh will fall back to rlimit on older kernels. that means it's safe to configure with seccomp_filter
Comment by Gaetan Bisson (vesath) - Wednesday, 01 August 2012, 07:52 GMT
Let's wait for 6.1 and see what sandbox ./configure autoselects then.

Loading...