Bug 2752 - Allow syscalls for openssl engines on s390x
Summary: Allow syscalls for openssl engines on s390x
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 7.5p1
Hardware: Other Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_8_1
  Show dependency treegraph
 
Reported: 2017-07-29 05:59 AEST by ebarretto
Modified: 2021-04-23 15:08 AEST (History)
3 users (show)

See Also:


Attachments
tarball containing the 3 patches (1.38 KB, application/x-compressed-tar)
2017-07-29 05:59 AEST, ebarretto
no flags Details
Allow-flock-and-ipc-syscall-for-s390-architecture (1.36 KB, patch)
2017-09-22 09:29 AEST, Damien Miller
no flags Details | Diff
Allow-getuid-and-geteuid-calls (1.08 KB, patch)
2017-09-22 09:30 AEST, Damien Miller
dtucker: ok+
Details | Diff
Enable-specific-ioctl-call-for-EP11-crypto-card-s390 (1.04 KB, patch)
2017-09-22 09:30 AEST, Damien Miller
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description ebarretto 2017-07-29 05:59:54 AEST
Created attachment 3025 [details]
tarball containing the 3 patches

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 and scp.

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, please check here:
https://github.com/opencryptoki/opencryptoki

2. getuid and geteuid are allowed to any architecture as this is also needed by the distros. libica and other crypto libraries use those syscalls.

3. The ioctl is allowed when an specific argument is passed. This argument
is from EP11 crypto card on s390 architecture.
For more information check here:
http://elixir.free-electrons.com/linux/latest/source/arch/s390/include/uapi/asm/zcrypt.h#L259

The patches were sent to the mailing list as well: https://www.spinics.net/lists/openssh-unix-dev/msg04133.html
Comment 1 Damien Miller 2017-09-22 09:29:55 AEST
Created attachment 3055 [details]
Allow-flock-and-ipc-syscall-for-s390-architecture
Comment 2 Damien Miller 2017-09-22 09:30:13 AEST
Created attachment 3056 [details]
Allow-getuid-and-geteuid-calls
Comment 3 Damien Miller 2017-09-22 09:30:28 AEST
Created attachment 3057 [details]
Enable-specific-ioctl-call-for-EP11-crypto-card-s390
Comment 4 Darren Tucker 2017-09-22 09:45:13 AEST
Comment on attachment 3055 [details]
Allow-flock-and-ipc-syscall-for-s390-architecture

sysV IPC seems like a big increase in attack surface even when this hardware is not in use?
Comment 5 Damien Miller 2017-09-22 10:02:05 AEST
Yeah, I agree. Would it be feasible to skip using the engines in the pre-auth phase entirely?
Comment 6 ebarretto 2017-09-22 22:46:53 AEST
(In reply to Damien Miller from comment #5)
> Yeah, I agree. Would it be feasible to skip using the engines in the
> pre-auth phase entirely?

Hi Damien,

We have on S390 two OpenSSL Engines, one more specific (is specific for one crypto card) and one more generic that works with different crypto card/devices. The first is openssl-ibmca and the last one openssl-ibmpkcs11.

We already did some changes on the seccomp filter (openssh-7.5) for the ibmca engine, but the getuid and geteuid was missing as it was enabled on some distro's openssh package but not on others.
Can we get the getuid and geteuid patch integrated for now? 

The other engine, ibmpkcs11, which needs the sysv ipc is not yet released and we can work on an alternative based on your feedback. 

This works for you? 

Thanks,
Eduardo
Comment 7 Damien Miller 2018-05-25 13:56:00 AEST
I've committed the getuid patch.

wrt the remaining patches:

There isn't much point in permitting flock() - the process is in a chroot environment and all fs operations should fail here. Could we SC_DENY it with ENOENT or EACCESS instead?

The ipc(2) syscall is much too broad to allow in a sandbox - it includes a number of capabilities that could be used for sandbox escape. Is there a safe subset that could be enabled?

Is there any documentation on the ZSENDEP11CPRB ioctl?
Comment 8 Jakub Jelen 2019-10-03 23:56:26 AEST
Eduardo, are these changes still needed? I am interested mostly in the ZSENDEP11CPRB, which is carried in most of the distros (suse, ubuntu, fedora), but not yet merged because of unanswered question in the last comment.
My searches on the interned did not uncover anything interesting, but mostly kernel drivers source code and examples [1].

Damien, would it be possible to merge this as there are already many others ioctls for s390 in, from commits b3a77b25e, e3ea335ab and 5f1596e11 ?

[1] https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lkdd/lkdd_r_zcryptctl_cmd.html
Comment 9 Damien Miller 2019-10-05 18:31:26 AEST
Applied and will be in OpenSSH 8.1
Comment 10 Damien Miller 2021-04-23 15:08:49 AEST
closing resolved bugs as of 8.6p1 release