Repository navigation
Enforce OpenSSH certificate permit-* extensions - #1392
ejohnstown wants to merge 2 commits into
Conversation
OsshCertCheckOptions now sets a WOLFSSH_OSSH_PERMIT_* bit in WS_OsshCert for each permit-* extension the certificate carries; one that is absent stays denied, as in OpenSSH. The bits reach the user auth callback as authData->sf.publicKey.permits, next to force-command, for the application to enforce. - WOLFSSH_OSSH_PERMIT_* bits and the permits member in ssh.h - api test: each extension, none, near-miss names, the vectors Issue: F-10589
A user who logs in with an OpenSSH certificate now gets CHANNEL_FAILURE for pty-req, x11-req and [email protected] unless the certificate carries permit-pty, permit-X11-forwarding or permit-agent-forwarding, as OpenSSH sshd does. Plain key and password logins are not affected. - CertPermitRequestCb on the channel request callback that sees all - sshd cert test: pty, X11, agent and forwarding with and without the extension, from the OpenSSH client - renew-ossh-certs.sh: clear, no-pty, no-agent and no-x11 certs - wolfSSHD_AuthSetCert records the permits only once the force-command copy succeeds; test_configuration covers a failed copy Issue: F-10589
|
@claude review |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
I reviewed this PR and didn't find any bugs. It changes how wolfsshd enforces certificate-based access restrictions, so a human should also look at it.
What was reviewed:
OsshCertCheckOptionssetspermitsto zero first, so any permit-* extension the certificate doesn't list is denied.DoUserAuthRequestPublicKeycopies that mask intoWS_UserAuthData_PublicKey.permits.CertPermitRequestCbgetsconnfromwolfSSH_SetChannelReqCtx. The library calls it before its built-in pty-req, x11-req and auth-agent-req handling, and returningWOLFSSH_REQ_REJECTskips that handling.UserAuthResultnow records the permits for every OpenSSH certificate login, not only ones with a force-command. If saving the force-command fails, the error is returned and nothing is recorded. Port forwarding and permit-user-rc are still not enforced, as the PR description says.
Extended reasoning...
The change adds parsing of OpenSSH certificate permit-* extensions in src/ossh.c and src/internal.c, plus a new public bitmask in wolfssh/ssh.h. It also adds enforcement in wolfsshd through a catch-all channel-request callback, with new tests in tests/api.c, test_configuration.c and the shell test. It touches security-sensitive code: authentication and permission enforcement in the SSH server. The decision to defer rests on two things: it gates which session features an authenticated user gets, and it adds a public API/ABI field. Both deserve a maintainer's look even though no defects were found.
wolfSSL-Fenrir-bot
left a comment
wolfSSL-Fenrir-bot
left a comment
There was a problem hiding this comment.
Fenrir Automated Review — PR #1392
Scan targets checked: wolfssh-src, wolfssh-bugs
Not reviewed (no scan target covers them): apps/wolfsshd/auth.h, apps/wolfsshd/test/sshd_ossh_cert_test.sh, keys/renew-ossh-certs.sh
Coverage: 8 of 8 in-scope changed file(s) opened by the reviewer
Fenrir result: Approved ✅
No new issues found in the changed files.
Advisory only — this automated result does not count as a GitHub approval.
Review tier: Max
WS_OsshCert records each permit-* extension a certificate carries,
absent ones denied as in OpenSSH, and passes them to the user auth
callback. wolfsshd refuses what a certificate does not permit.
certificate denies; port forwarding and user rc are not gated yet
Issue: F-10589