[Bug 2833] The code in opennsd-compat/port-solaris.c should not change PRIV_LIMIT when PRIV_XPOLICY is set.
https://bugzilla.mindrot.org/show_bug.cgi?id=2833
ron.jor...@oracle.com changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from ron.jor...@oracle.com ---
This issue will immediately be addressed in Solaris 11 by Oracle via a
patch. This patch is being offered for inclusion upstream:
diff -ur orig/openbsd-compat/port-solaris.c
new/openbsd-compat/port-solaris.c
--- orig/openbsd-compat/port-solaris.c Tue Feb 6 08:22:44 2018
+++ new/openbsd-compat/port-solaris.c Tue Feb 6 08:45:21 2018
@@ -306,6 +306,31 @@
priv_delset(npset, PRIV_PROC_SESSION) != 0)
fatal("priv_delset: %s", strerror(errno));
+#ifdef PRIV_XPOLICY
+ /*
+* It is possible that the user has an extended policy
+* in place; the LIMIT set restricts the extended policy
+* and so should not be restricted.
+* PRIV_XPOLICY is newly defined in Solaris 11 though the
extended
+* policy was not implemented until Solaris 11.1.
+*/
+ if (getpflags(PRIV_XPOLICY) == 1) {
+ if (getppriv(PRIV_LIMIT, pset) != 0)
+ fatal("getppriv: %s", strerror(errno));
+
+ priv_intersect(pset, npset);
+
+ if (setppriv(PRIV_SET, PRIV_LIMIT, npset) != 0)
+ fatal("setppriv: %s", strerror(errno));
+ } else
+#endif
+ {
+ /* Cannot exec, so we can kill the limit set. */
+ priv_emptyset(pset);
+ if (setppriv(PRIV_SET, PRIV_LIMIT, pset) != 0)
+ fatal("setppriv: %s", strerror(errno));
+ }
+
if (getppriv(PRIV_PERMITTED, pset) != 0)
fatal("getppriv: %s", strerror(errno));
@@ -312,7 +337,6 @@
priv_intersect(pset, npset);
if (setppriv(PRIV_SET, PRIV_PERMITTED, npset) != 0 ||
- setppriv(PRIV_SET, PRIV_LIMIT, npset) != 0 ||
setppriv(PRIV_SET, PRIV_INHERITABLE, npset) != 0)
fatal("setppriv: %s", strerror(errno));
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2833] New: The code in opennsd-compat/port-solaris.c should not change PRIV_LIMIT when PRIV_XPOLICY is set.
https://bugzilla.mindrot.org/show_bug.cgi?id=2833 Bug ID: 2833 Summary: The code in opennsd-compat/port-solaris.c should not change PRIV_LIMIT when PRIV_XPOLICY is set. Product: Portable OpenSSH Version: 7.5p1 Hardware: Other OS: Solaris Status: NEW Severity: normal Priority: P5 Component: sftp-server Assignee: unassigned-b...@mindrot.org Reporter: ron.jor...@oracle.com The code in opennsd-compat/port-solaris.c should not change PRIV_LIMIT when PRIV_XPOLICY is set. In Solaris, it is possible for a user to have an extended policy in place; the LIMIT set restricts the extended policy and so should not be restricted. -- You are receiving this mail because: You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2652] PKCS11 login skipped if login required and no pin set
https://bugzilla.mindrot.org/show_bug.cgi?id=2652 --- Comment #14 from Jakub Jelen --- (In reply to Daniel Kucera from comment #13) > (In reply to Jakub Jelen from comment #12) > > Prompting for the PIN for public key operations is nothing we would > > like to do automatically, so there really should be some switch to > > do the login before listing the keys or the login should be proposed > > explicitly by for example a PIN in PKCS#11 URI. > > I see two reasonable options here: either to check return of all > functions for CKR_USER_NOT_LOGGED_IN return code and retry them > after login If you do not see any objects on the card before login, you will not get any such error so this will not resolve your problem in any way. > or login always when CKF_LOGIN_REQUIRED is set. That is not sane default behavior. With most of the cards, certificates and public keys are visible without login. For the few others, there should be configuration option to handle this case as I initially proposed in the referenced bug. > Moreover, not every time when you call login with NULL pin you are > required to put it in. In my case the library ask for it only time > to time (you can see my usecase here: > https://blog.danman.eu/ssh-autentifikacia-s-eid-obcianskym-preukazom- > pod-linuxom/ ) probably because it keeps the session with card open. >From the log, it looks like CardOS V5.0 card, which should work also with the latest OpenSC. The PKCS#11 module you are using is probably somehow holding the login state of your card and presents you its own PIN pad in GUI. That is certainly not a standard behavior of PKCS#11 modules nor cards. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2652] PKCS11 login skipped if login required and no pin set
https://bugzilla.mindrot.org/show_bug.cgi?id=2652 --- Comment #13 from Daniel Kucera --- (In reply to Jakub Jelen from comment #12) > > Prompting for the PIN for public key operations is nothing we would > like to do automatically, so there really should be some switch to > do the login before listing the keys or the login should be proposed > explicitly by for example a PIN in PKCS#11 URI. I see two reasonable options here: either to check return of all functions for CKR_USER_NOT_LOGGED_IN return code and retry them after login or login always when CKF_LOGIN_REQUIRED is set. Moreover, not every time when you call login with NULL pin you are required to put it in. In my case the library ask for it only time to time (you can see my usecase here: https://blog.danman.eu/ssh-autentifikacia-s-eid-obcianskym-preukazom-pod-linuxom/ ) probably because it keeps the session with card open. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2652] PKCS11 login skipped if login required and no pin set
https://bugzilla.mindrot.org/show_bug.cgi?id=2652 --- Comment #12 from Jakub Jelen --- (In reply to Daniel Kucera from comment #11) > (In reply to Jakub Jelen from comment #10) > > Thank you for testing the patch. But your changes again change the > > semantics and issue the pinpad login even if the PIN is NULL, which > > is not what you generally want. > > But if CKF_LOGIN_REQUIRED is set why would one want to skip login? The PKCS#11 specification does not say what can and what can not be accessed if this flag is provided: > CKF_LOGIN_REQUIRED: True if there are *some* cryptographic functions that a > user MUST be logged in to perform From: http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html We do not skip login for the private-key operations, but only for the listing of the keys, which is a valid use case. > > Or is your card requiring the login also for the listing of public > > keys? What do you get if you try to list the public objects from > > pkcs11-tool? > > > > pkcs11-tool -O /usr/lib/eidklient/libpkcs11_sig_x64.so > > My card requires login for absolutely everything > > $ pkcs11-tool -vvv --module /usr/lib/eidklient/libpkcs11_sig_x64.so > -O > Using slot 0 with a present token (0x1) > $ pkcs11-tool -vvv --module /usr/lib/eidklient/libpkcs11_sig_x64.so > -l -O > Using slot 0 with a present token (0x1) > Private Key Object; RSA > label: 571cd7f3-0935-4218-b7cf-4b43af29d1bc > ID: ... > Usage: decrypt, sign > Access: always authenticate > Certificate Object; type = X.509 cert > label: 571cd7f3-0935-4218-b7cf-4b43af29d1bc > ID: ... Yes, this is the same problem as described in the bug #2430 some while back, which I hit with some soft tokens and that are also visible in eID cards as I tried to point out. Prompting for the PIN for public key operations is nothing we would like to do automatically, so there really should be some switch to do the login before listing the keys or the login should be proposed explicitly by for example a PIN in PKCS#11 URI. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
[Bug 2784] Add native support for routing domains / VRF
https://bugzilla.mindrot.org/show_bug.cgi?id=2784 --- Comment #38 from Luca Boccassi --- > once cgroups v2 is stable and full-featured. I admire your optimism! :-D Yes I agree that it's a bit invasive as there are multiple sockets and features to account for, and for the normal use case ip exec will suffice when cgoups2 is complete (hope to see that before I retire :-P ). There are other corner cases where, unless I'm mistaken, I think that won't be enough though - for example, doing forwarding over a vrf and connecting via another, eg: ssh -r vrf-blue -L 192.168.122.1:9001:localhost:6 192.168.122.1 or ssh -L 192.168.122.1:9001:vrf-blue:localhost:6 192.168.122.1 Since ip exec is an "all or nothing" deal (I'm not sure if there is a BSD equivalent). Do you know of a way to achieve the same functionality without changing the client? Now strictly speaking I don't need these cases at $work so I'm not too fussed about it, but some other users might want that at some point so I thought it would be worth at least mentioning. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. ___ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs
