From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755467AbZCKMxq (ORCPT ); Wed, 11 Mar 2009 08:53:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753771AbZCKMxh (ORCPT ); Wed, 11 Mar 2009 08:53:37 -0400 Received: from rv-out-0506.google.com ([209.85.198.225]:49521 "EHLO rv-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753021AbZCKMxg (ORCPT ); Wed, 11 Mar 2009 08:53:36 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=HltnvKQURFf5AJfYPOd7GB1eRqIjQ9+NmV7xP+FfVPiC1a4IiF6vkxCt7XdFbt/PWf 7HbJWDbS//g1N6AW7hiqReRv4iIpGAwL+3L1+9fjjUJDEXo7KTmdiiqUPBKEYldAulLS CfHkA9TzR+txxX9JKI7zx3Z2a8Qq1d+SrDwX0= MIME-Version: 1.0 Date: Wed, 11 Mar 2009 15:53:34 +0300 Message-ID: Subject: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? From: Igor Zhbanov To: linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, bfields@fieldses.org, neilb@suse.de, Trond.Myklebust@netapp.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! It seems that CAP_MKNOD and CAP_LINUX_IMMUTABLE were forgotten to be added to CAP_FS_MASK_B0 in linux-2.6.x and to CAP_FS_MASK in linux-2.4.x. Both capabilities affects file system and can be considered file system capabilities. Let's look at linux-2.6.x. In include/linux/capability.h CAP_FS_SET is defined to contain following capabilities: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID and CAP_MAC_OVERRIDE. And CAP_NFSD_SET is defined to be the same plus CAP_SYS_RESOURCE. So, both CAP_FS_SET and CAP_NFSD_SET doesn't include CAP_MKNOD and CAP_LINUX_IMMUTABLE. Also include/linux/capability.h there are cap_drop_fs_set(...), cap_raise_fs_set(...), cap_drop_nfsd_set(...) and cap_raise_nfsd_set(...) inline functions that return corresponding capabilities sets. Let's look how these functions are used. In file fs/nfsd/auth.c function nfsd_setuser(...) calls cap_raise_nfsd_set(...) and cap_drop_nfsd_set(...) to add/exclude corresponding capabilities to/from effective set of current nfsd process. And in file security/commoncap.c function cap_task_post_setuid(...) calls cap_drop_fs_set(...) and cap_raise_fs_set(...) to change effective set of current task when (current->fsuid != old_ruid). In linux-2.4.x the story is the same. In file include/linux/capability.h CAP_FS_MASK is defined to contain CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID capabilities. And in file fs/nfsd/auth.c CAP_NFSD_MASK is defined to be same as CAP_FS_MASK plus CAP_SYS_RESOURCE. In file fs/nfsd/auth.c function nfsd_setuser(...) uses CAP_NFSD_MASK to add/exclude corresponding capabilities to/from effective set of current nfsd process. And CAP_FS_MASK used in file kernel/sys.c in function sys_setfsuid(...) to add/exclude corresponding capabilities to/from effective set of current task. This can be exploited (and I have succesfully tried it). Suppose you have NFS-share exported even with root_squash option. If one client was compromised, local root can set CAP_MKNOD to some local user's process. Then that user can execute mknod to create a device that will be owned by that user, e.g. block device file for /dev/hda hard drive. And he can create that device file on NFS-share (even exported with root_squash option). After that he can someway (ssh, cgi) execute code on another nfs client or the server to modify it's filesystem. It will be possible because he owns that device file on nfs share. The problem is because CAP_MKNOD allows that user to successfully execute vfs_mknod(...) function on local host, and that function will call corresponding function in nfs module which sends request to NFS server. And nfsd will not drop CAP_MKNOD in nfsd_setuser(...) function when impersonating to that user. Of course, NFS-shares can be mounted with nodev option, but they should be placed on separate partition on NFS-server, so even on server that partition is mounted with nodev option too. So I suggest to add CAP_MKNOD and CAP_LINUX_IMMUTABLE to CAP_FS_MASK in linux-2.4.x and to CAP_FS_MASK_B0 in linux-2.6.x.