LABBE Corentin
2015-Feb-25 13:09 UTC
[openssh with openssl cryptodev engine] sshd killed by seccomp filter
Hello I have a server with an hardware crypto accelator. For giving userspace access to it I use the cryptodev module (http://cryptodev-linux.org/) I have also the cryptodev engine compiled in openssl. When I modprobe the cryptodev module, I cannot login with ssh on the server. The symptom can be found with dmesg: audit: type=1326 audit(1424784807.257:3): auid=4294967295 uid=22 gid=22 ses=4294967295 pid=17725 comm="sshd" exe="/usr/sbin/sshd" sig=31 arch=40000028 syscall=54 compat=0 ip=0xb6be809c code=0x0 sshd is killed by SIGSYS, because it try to use the ioctl call which is forbiden by the seccomp filter. If you check the openssl engine code, it use ioctl on /dev/crypto. The following patch solve the issue: --- sandbox-seccomp-filter.c.old 2015-02-24 14:52:01.000000000 +0100 +++ sandbox-seccomp-filter.c 2015-02-24 15:45:08.000000000 +0100 @@ -98,6 +98,7 @@ #ifdef __NR_time /* not defined on EABI ARM */ SC_ALLOW(time), #endif + SC_ALLOW(ioctl), SC_ALLOW(read), SC_ALLOW(write), SC_ALLOW(close), Thanks
Damien Miller
2015-Feb-25 17:21 UTC
[openssh with openssl cryptodev engine] sshd killed by seccomp filter
On Wed, 25 Feb 2015, LABBE Corentin wrote:> Hello > > I have a server with an hardware crypto accelator. > For giving userspace access to it I use the cryptodev module (http://cryptodev-linux.org/) > I have also the cryptodev engine compiled in openssl. > > When I modprobe the cryptodev module, I cannot login with ssh on the server. > > The symptom can be found with dmesg: > audit: type=1326 audit(1424784807.257:3): auid=4294967295 uid=22 gid=22 ses=4294967295 pid=17725 comm="sshd" exe="/usr/sbin/sshd" sig=31 arch=40000028 syscall=54 compat=0 ip=0xb6be809c code=0x0[snip]> + SC_ALLOW(ioctl),no, sorry. ioctl is too much attack kernel surface and would defeat the usefulness of the sandbox. -d
Ángel González
2015-Feb-25 22:07 UTC
[openssh with openssl cryptodev engine] sshd killed by seccomp filter
On 25/02/15 18:21, Damien Miller wrote:> On Wed, 25 Feb 2015, LABBE Corentin wrote: >> + SC_ALLOW(ioctl), > no, sorry. ioctl is too much attack kernel surface and would defeat the > usefulness of the sandbox. > > -dLabbe, which ioctl is being issued?