Arjan van de Ven wrote:
it's not that kind of thing. It's basically a public key encryption
step. Putting it in the kernel can only serve one purpose: to be there
to allow other parts to use this pke for encrypting/signing/verifying
signatures.
...
3) to allow kernel pieces to do key things, like the secure nfs parts of
nfsv4 or ipsec.
That can still deadlock. If write or writepage or writepages requires
a network frame to be signed and
an upcall occurs in that path ... For example cifs has long had
signature code in kernel (depends on MD5
code in kernel, which because it is so small has not been controversial
presumably) and write requests
(which can be necessary to flush inode data when the system is low on
memory) are signed
and of course of types of frames are signed in cases where various
semaphores on the parent directory
or inode are held by the vfs. This signing is done in kernel and at
least when authenticated with NTLM
(and presumably NTLMv2 as well) has turned out to be fairly simple.
Note that for many or most
cifs servers in modern day domains packet signatures are required by
default (unlike four or five years
ago when it was less common). A key issue that I have not worked
through is whether this would change
as SPNEGO authentication negotiates PKI or Kerberos like tickets - and
whether any of this in kernel
infrastructure being discussed would be needed for the common case of
cifs (beyond what
we already have with MD5 packet signatures) or helpful for the case when
Kerberos/SPNEGO authentication is negotiated (code that is not yet
complete in cifs, but will
probably be 90% done in userspace) because CIFS packet signing when
Kerberos is
authenticated (or when an alternative some x509/SPNEGO pki variant is
more commonly
seem from e.g. Windows servers or NAS appliances) different signing code
may be required -
and since the SMB WriteX frame would have to be signed ... it would be
very risky to upcall if
we find out that packet signing for the very, very common case (more
than 2/3 of enterprises today)
of Kerberized cifs sessions requires an encrypting/signing/verifying
mechanism that is not in kernel.
Beyond the issue of how to handle the newer version of packet signing,
my main interest in the
calling the keyring code from kernel (from cifs vfs) is using it to
determining more precisely
what the "kerberos identity" of the current process is (ie what is the
"user@realm" for the current
process and do I have an authenticated session for him - so I can map
the right smb_uid (in effect
a handle to the network security context for the smb session) for the
header of the SMB/CIFS
network file requests coming from any particular process).
A secondary benefit of the keyring infrastructure, an issue that I hear
frequently from advanced users, an
issue that the kernel keyring may eventually solve is allowing me to
automatically authenticate without all local
users having to resupply the password for every local mount (in
particular when /proc/fs/cifs/MultiuserMount
is enabled). Currently each unique user logged on to a system
typically authenticates through pam but
kernel code has no access to the password that was supplied earlier at
logon time, unless it is passed again
explicitly on mount. There are common cases in which users would logon
locally with the same userid/password
as they would supply to mount to a remote server (especially when users
authenticate to a central
security server through pam_winbind or pam_ldap, pam_kerberos) - in
those cases I hope someday that
an optional pam module is available which saves the password (or in my
case there is also a one way hash of the
password which would be fine) in the kernel key ring so cifs does not
have to upcall in the middle of
an operation (from what to cifs is a new user for this mount) to prompt
the user at runtime for a password (which
would be awful). Currently users have to mount to the same server (and
export) multiple times, once with
each uid/user/password combination - and the keyring would solve this if
there were an optional pam module that
could save passwords (and eventually kerberos tickets too) securely in
kernel in the keyring.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
