[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#991936: openssh-server: seccomp filter defaults to SIGSYS, could break any libc or kernel upgrade



Control: severity -1 important
Control: tag -1 upstream
Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3478

On Fri, Aug 06, 2021 at 11:29:15AM +0200, Julian Andres Klode wrote:
> seccomp filters are currently setup to kill the process
> 
>     #define SECCOMP_FILTER_FAIL SECCOMP_RET_KILL
> 
>     /* Default deny */
>         BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL),
> 
> this means every new libc or kernel release can cause openssh
> to break, requiring breaks from them on openssh, which does not
> scale, and is currently breaking SSH during upgrades.
> 
> This also means openssh might fail to work inside containers
> because the host kernel is newer.
> 
> The default policy needs to be changed to return ENOSYS instead,
> such that libc can fallback to other syscalls for its wrappers.
> With the caveat that umask is a bit broken, if you don't want to
> allow it, block it explicitly with RET_KILL:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1724098
> 
> This should be fixed for bullseye+1, and fixed in a point release
> IMO, it might be a tad too late right now for the release itself.

I agree this is at least a problem waiting to happen and a noticeable
inconvenience for stable release maintenance, so I've (belatedly)
forwarded it upstream with a suggested patch.  The sandbox is
security-critical enough that I don't want to patch fundamental things
about its behaviour without upstream's consent, so we'll see what they
make of my suggestion.

I don't think this needs to be release-critical.  It's a significant
problem and I'd definitely like it to be fixed, but mostly this change
would protect us against specific manifestations of syscall filtering
problems that would be grave bugs, rather than being intrinsically RC.
As such I'm downgrading it a step for now.

Thanks,

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]


Reply to: