[lkml]   [2006]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library
    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

    >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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-01-29 22:44    [W:0.024 / U:45.484 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site