06 Aug, 2010

1 commit

  • Separate out the DNS resolver key type from the CIFS filesystem into its own
    module so that it can be made available for general use, including the AFS
    filesystem module.

    This facility makes it possible for the kernel to upcall to userspace to have
    it issue DNS requests, package up the replies and present them to the kernel
    in a useful form. The kernel is then able to cache the DNS replies as keys
    can be retained in keyrings.

    Resolver keys are of type "dns_resolver" and have a case-insensitive
    description that is of the form "[:]". The optional
    indicates the particular DNS lookup and packaging that's required. The
    is the query to be made.

    If isn't given, a basic hostname to IP address lookup is made, and the
    result is stored in the key in the form of a printable string consisting of a
    comma-separated list of IPv4 and IPv6 addresses.

    This key type is supported by userspace helpers driven from /sbin/request-key
    and configured through /etc/request-key.conf. The cifs.upcall utility is
    invoked for UNC path server name to IP address resolution.

    The CIFS functionality is encapsulated by the dns_resolve_unc_to_ip() function,
    which is used to resolve a UNC path to an IP address for CIFS filesystem. This
    part remains in the CIFS module for now.

    See the added Documentation/networking/dns_resolver.txt for more information.

    Signed-off-by: Wang Lei
    Signed-off-by: David Howells
    Acked-by: Jeff Layton
    Signed-off-by: Steve French

    Wang Lei
     

31 Jul, 2010

1 commit


23 Jul, 2010

1 commit

  • Fix the security problem in the CIFS filesystem DNS lookup code in which a
    malicious redirect could be installed by a random user by simply adding a
    result record into one of their keyrings with add_key() and then invoking a
    CIFS CFS lookup [CVE-2010-2524].

    This is done by creating an internal keyring specifically for the caching of
    DNS lookups. To enforce the use of this keyring, the module init routine
    creates a set of override credentials with the keyring installed as the thread
    keyring and instructs request_key() to only install lookup result keys in that
    keyring.

    The override is then applied around the call to request_key().

    This has some additional benefits when a kernel service uses this module to
    request a key:

    (1) The result keys are owned by root, not the user that caused the lookup.

    (2) The result keys don't pop up in the user's keyrings.

    (3) The result keys don't come out of the quota of the user that caused the
    lookup.

    The keyring can be viewed as root by doing cat /proc/keys:

    2a0ca6c3 I----- 1 perm 1f030000 0 0 keyring .dns_resolver: 1/4

    It can then be listed with 'keyctl list' by root.

    # keyctl list 0x2a0ca6c3
    1 key in keyring:
    726766307: --alswrv 0 0 dns_resolver: foo.bar.com

    Signed-off-by: David Howells
    Reviewed-and-Tested-by: Jeff Layton
    Acked-by: Steve French
    Signed-off-by: Linus Torvalds

    David Howells
     

08 Feb, 2008

1 commit


11 Jan, 2008

1 commit