From: Steve French <smfrench@austin.rr.com>
To: Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, keyrings@linux-nfs.org
Subject: Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library
Date: Sun, 29 Jan 2006 15:41:03 -0600 [thread overview]
Message-ID: <43DD366F.9080906@austin.rr.com> (raw)
In-Reply-To: <1138567954.17148.4.camel@laptopd505.fenrus.org>
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.
next prev parent reply other threads:[~2006-01-29 21:41 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-26 21:58 [PATCH 00/04] Add DSA key type David Härdeman
2006-01-26 21:58 ` [PATCH 03/04] Add encryption ops to the keyctl syscall David Härdeman
2006-01-26 21:58 ` [PATCH 02/04] Add dsa crypto ops David Härdeman
2006-01-26 21:58 ` [PATCH 01/04] Add multi-precision-integer maths library David Härdeman
2006-01-27 9:28 ` Christoph Hellwig
2006-01-27 20:07 ` David Howells
2006-01-27 20:41 ` David Härdeman
2006-01-27 22:19 ` [Keyrings] " Trond Myklebust
2006-01-27 23:35 ` Kyle Moffett
2006-01-28 0:27 ` Adrian Bunk
2006-01-28 3:45 ` Trond Myklebust
2006-01-28 7:17 ` Kyle Moffett
2006-01-28 10:39 ` Adrian Bunk
2006-01-28 0:22 ` Adrian Bunk
2006-01-28 10:46 ` David Härdeman
2006-01-28 13:03 ` Adrian Bunk
2006-01-28 17:09 ` David Härdeman
2006-01-28 16:37 ` [Keyrings] " Trond Myklebust
2006-01-28 16:57 ` David Härdeman
2006-01-29 3:20 ` Trond Myklebust
2006-01-29 11:33 ` David Härdeman
2006-01-29 12:29 ` Adrian Bunk
2006-01-29 13:09 ` Arjan van de Ven
2006-01-29 20:05 ` Steve French
2006-01-29 20:52 ` Arjan van de Ven
2006-01-29 21:41 ` Steve French [this message]
2006-02-06 12:31 ` David Howells
2006-01-29 23:18 ` Adrian Bunk
2006-01-29 13:18 ` David Härdeman
2006-01-29 23:36 ` Adrian Bunk
2006-01-30 18:09 ` Nix
2006-01-29 16:38 ` Trond Myklebust
2006-01-29 18:49 ` Dax Kelson
2006-01-29 19:10 ` Trond Myklebust
2006-01-29 21:29 ` David Härdeman
2006-01-29 21:46 ` Trond Myklebust
2006-01-29 21:13 ` David Härdeman
2006-01-29 21:28 ` Trond Myklebust
2006-01-29 22:02 ` David Härdeman
2006-01-29 22:05 ` Trond Myklebust
2006-01-29 22:54 ` Kyle Moffett
2006-01-29 23:07 ` Trond Myklebust
2006-01-29 23:15 ` Adrian Bunk
2006-01-29 21:09 ` Pavel Machek
2006-01-26 21:58 ` [PATCH 04/04] Add dsa key type David Härdeman
2006-01-27 1:10 ` [PATCH 00/04] Add DSA " Herbert Xu
2006-01-27 7:18 ` David Härdeman
2006-01-27 20:11 ` David Howells
2006-01-27 23:22 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43DD366F.9080906@austin.rr.com \
--to=smfrench@austin.rr.com \
--cc=arjan@infradead.org \
--cc=keyrings@linux-nfs.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).