similar to: [PATCH] seccomp: allow the getrandom system call.

This patch enables specific ioctl calls for ICA crypto card on s390 platform. Without this patch, users using the IBMCA engine are not able to perform ssh login as the filter blocks the communication with the crypto card. Signed-off-by: Harald Freudenberger <freude at linux.vnet.ibm.com> Signed-off-by: Eduardo Barretto <ebarretto at linux.vnet.ibm.com> --- sandbox-seccomp-filter.c |

I've committed this diff. Please test and confirm that it works ok. (If not, then I've botched the macro fixes in the previous commit) Thanks, Damien Miller On Tue, 14 Mar 2017, Damien Miller wrote: > ok, with the fixes for the seccomp-bpf sandbox that I just committed > the diff reduces to. > > IMO this is scoped narrowly enough to go in. > > -d > > diff

This patchset allow syscalls (flock, ipc, getuid, geteuid and ioctl), so openssl engines, e.g. OpenSSL-ibmca and OpenSSL-ibmpkcs11, can work and communicate with the crypto cards during ssh login. 1. The flock and ipc are allowed only for s390 architecture. They are needed for openCryptoki project (PKCS#11 implementation), as the ibmpkcs11 engine makes use of openCryptoki. For more information,

On 03-03-2017 09:54, Petr Cerny wrote: > Damien Miller wrote: >> On Tue, 28 Feb 2017, Eduardo Barretto wrote: >> >>> On 13-02-2017 13:23, Eduardo Barretto wrote: >>> > This patch enables specific ioctl calls for ICA crypto card on s390 >>> > platform. Without this patch, users using the IBMCA engine are not >>> able >>> > to

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2361 Bug ID: 2361 Summary: seccomp filter (not only) for aarch64 Product: Portable OpenSSH Version: 6.7p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at

On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller <smueller at chronox.de> wrote: > And finally, you have a coding error that is very very common but fatal when > reading from /dev/random: you do not account for short reads which implies > that your loop continues even in the case of short reads. > > Fix your code with something like the following: > int read_random(char

On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller <smueller at chronox.de> wrote: > And finally, you have a coding error that is very very common but fatal when > reading from /dev/random: you do not account for short reads which implies > that your loop continues even in the case of short reads. > > Fix your code with something like the following: > int read_random(char

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a

Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 15:12:30 +0200 > > Stephan Mueller <smueller at chronox.de> wrote as excerpted: > > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > > In my opinion, assuming I am not doing something terribly wrong, > > > this constitutes a bug in the kernel's

Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 15:12:30 +0200 > > Stephan Mueller <smueller at chronox.de> wrote as excerpted: > > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > > In my opinion, assuming I am not doing something terribly wrong, > > > this constitutes a bug in the kernel's

Pulling header files directly out of the kernel sources for inclusion in userspace programs is highly error prone, not least because it bypasses the kbuild infrastructure entirely and so may end up referencing other header files that have not been generated. Subsequent patches will cause compiler.h to pull in the ungenerated asm/rwonce.h file via filter.h, breaking the build for tools/bpf: | $

Pulling header files directly out of the kernel sources for inclusion in userspace programs is highly error prone, not least because it bypasses the kbuild infrastructure entirely and so may end up referencing other header files that have not been generated. Subsequent patches will cause compiler.h to pull in the ungenerated asm/rwonce.h file via filter.h, breaking the build for tools/bpf: | $

https://bugzilla.mindrot.org/show_bug.cgi?id=3430 Bug ID: 3430 Summary: 64 bit time and seccomp conflict Product: Portable OpenSSH Version: 8.9p1 Hardware: ARM OS: Linux Status: NEW Severity: major Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org

On Fri, 29 Jul 2016 12:24:27 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller > <smueller at chronox.de> wrote: > > And finally, you have a coding error that is very very common but > > fatal when reading from /dev/random: you do not account for short > > reads which implies that your loop continues

On Fri, 29 Jul 2016 19:03:51 +0200 Stephan Mueller <smueller at chronox.de> wrote as excerpted: > Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: > > I don't follow. Assuming you are correct and this is the issue, then > > reading 128 bits (16 bytes) from /dev/random should "exhaust the > > supply" and then both reads from /dev/random and calling

Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 12:24:27 +0200 > > Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller > > > > <smueller at chronox.de> wrote: > > > And finally, you have a coding error that is very very common but > > > fatal

Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 12:24:27 +0200 > > Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller > > > > <smueller at chronox.de> wrote: > > > And finally, you have a coding error that is very very common but > > > fatal

https://bugzilla.mindrot.org/show_bug.cgi?id=3085 Bug ID: 3085 Summary: seccomp issue after upgrading openssl Product: Portable OpenSSH Version: 8.1p1 Hardware: Other OS: Linux Status: NEW Severity: critical Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org