bugzilla-daemon at bugzilla
May 18, 2012, 4:53 AM
Post #1 of 1
(56 views)
Permalink
|
|
[Bug 2011] New: sandbox selection needs some kind of fallback mechanism
|
|
https://bugzilla.mindrot.org/show_bug.cgi?id=2011
Bug #: 2011
Summary: sandbox selection needs some kind of fallback
mechanism
Classification: Unclassified
Product: Portable OpenSSH
Version: 6.0p1
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Build system
AssignedTo: unassigned-bugs [at] mindrot
ReportedBy: cjwatson [at] debian
At the moment, sandbox selection is done entirely at configure time,
and you get to pick exactly one. The seccomp_filter sandbox, at least,
probes the capabilities of the running kernel in configure.
This sort of approach is straightforward, but doesn't work well for
those of us distributing OpenSSH binaries that are likely to be run on
a different kernel version than is running on our build systems. For
example, my current setup for uploading to Debian is such that 32-bit
x86 binaries are built in a Debian unstable chroot on my laptop, which
runs a 64-bit Ubuntu kernel. Since Ubuntu's kernel packagers have
pulled in the seccomp patches from Will Drewry, but as far as I know
the Debian kernel hasn't, and the patches haven't quite landed in an
upstream Linux release yet, this means that by default if I build
OpenSSH 6.0p1 I'll end up with binaries that will fatal() on Debian
kernels, which would probably not make my users terribly happy.
Ideally, what I'd like to be able to do is build binaries that will try
to use seccomp_filter if the running kernel (checked at run-time, *not*
at build-time) supports it. That way I could build binaries that will,
say, use the rlimit sandbox on Linux <3.5 and the seccomp_filter
sandbox on Linux >=3.5 (or whatever version it actually lands in).
Otherwise I won't be able to enable seccomp_filter until I can be
absolutely sure that the binaries I'm building will never be used on
kernels that predate support for it; bearing in mind that sshd is
typically restarted on system upgrades long before rebooting into the
upgraded kernel, that's going to be years away.
I realise this is a problem specific to distributors, and even at that
I'm sure some distributors have the luxury of being able to assume that
kernel and userspace are in sync; so I'd be happy to try to put
together a patch for this, given a bit of direction. Would you prefer
a simple approach that just explicitly hands off from seccomp_filter to
rlimit until something more complex is needed, or would you prefer
something like:
struct Sandbox *sandboxes = {
#ifdef SANDBOX_SYSTRACE
sandbox_systrace,
#endif
...
sandbox_null
}
and then something that iterates over all the compiled-in sandboxes and
picks the first one whose init succeeds?
--
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
|
