From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH v2] fs: block cross-uid sticky symlinks Date: Sun, 30 May 2010 23:54:23 -0400 Message-ID: <1275278063.20730.16.camel@localhost> References: <20100531030402.GQ6056@outflux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, Randy Dunlap , Andrew Morton , Jiri Kosina , Dave Young , Martin Schwidefsky , James Morris , David Howells , Ingo Molnar , Peter Zijlstra , "Eric W. Biederman" , Tim Gardner , "Serge E. Hallyn" , sds@tycho.nsa.gov, selinux@tycho.nsa.gov To: Kees Cook Return-path: In-Reply-To: <20100531030402.GQ6056@outflux.net> Sender: linux-doc-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sun, 2010-05-30 at 20:04 -0700, Kees Cook wrote: > A long-standing class of security issues is the symlink-based > time-of-check-time-of-use race, most commonly seen in world-writable > directories like /tmp. The common method of exploitation of this flaw > is to cross privilege boundaries when following a given symlink (i.e.= a > root process follows a symlink belonging to another user). For a lik= ely > incomplete list of hundreds of examples across the years, please see: > http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=3D/tmp >=20 > The solution is to permit symlinks to only be followed when outside a= sticky > world-writable directory, or when the uid of the symlink and follower= match, > or when the directory owner matches the symlink's owner. >=20 > Some pointers to the history of earlier discussion that I could find: >=20 > 1996 Aug, Zygo Blaxell > http://marc.info/?l=3Dbugtraq&m=3D87602167419830&w=3D2 > 1996 Oct, Andrew Tridgell > http://lkml.indiana.edu/hypermail/linux/kernel/9610.2/0086.html > 1997 Dec, Albert D Cahalan > http://lkml.org/lkml/1997/12/16/4 > 2005 Feb, Lorenzo Hern=C3=A1ndez Garc=C3=ADa-Hierro > http://lkml.indiana.edu/hypermail/linux/kernel/0502.0/1896.html >=20 > Past objections and rebuttals could be summarized as: >=20 > - Violates POSIX. > - POSIX didn't consider this situation and it's not useful to foll= ow > a broken specification at the cost of security. > - Might break unknown applications that use this feature. > - Applications that break because of the change are easy to spot a= nd > fix. Applications that are vulnerable to symlink ToCToU by not h= aving > the change aren't. > - Applications should just use mkstemp() or O_CREATE|O_EXCL. > - True, but applications are not perfect, and new software is writ= ten > all the time that makes these mistakes; blocking this flaw at th= e > kernel is a single solution to the entire class of vulnerability= =2E >=20 > This patch is based on the patch in Openwall and grsecurity. I have > added a sysctl to toggle the behavior back to the old logic via > /proc/sys/fs/weak-sticky-symlinks, documentation, and a ratelimited > warning. >=20 > v2: > - dropped redundant S_ISLNK check. > - moved sysctl extern into security.h. > - asked to include CC to linux-fsdevel. We need to call this function in the SELinux case. So you'll need a patch like the one attached (not even compiled but I think it is right) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 5c9f25b..d6ebee2 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2668,8 +2668,13 @@ static int selinux_inode_readlink(struct dentry = *dentry) =20 static int selinux_inode_follow_link(struct dentry *dentry, struct nam= eidata *nameidata) { + int rc; const struct cred *cred =3D current_cred(); =20 + rc =3D cap_inode_follow_link(dentry, nameidata); + if (rc) + return rc; + return dentry_has_perm(cred, NULL, dentry, FILE__READ); } =20 > +int cap_inode_follow_link(struct dentry *dentry, > + struct nameidata *nameidata) > +{ > + const struct inode *parent =3D dentry->d_parent->d_inode; > + const struct inode *inode =3D dentry->d_inode; > + const struct cred *cred =3D current_cred(); > + > + if (weak_sticky_symlinks) > + return 0; > + > + if ((parent->i_mode & (S_ISVTX|S_IWOTH)) =3D=3D (S_ISVTX|S_IWOTH) &= & > + parent->i_uid !=3D inode->i_uid && > + cred->fsuid !=3D inode->i_uid) { > + printk_ratelimited(KERN_NOTICE "non-matching-uid symlink " > + "following attempted in sticky-directory by " > + "%s (fsuid %d)\n", current->comm, cred->fsuid); > + return -EACCES; > + } > + return 0; > +} What stops us from racing between the assignment of parent and it's first use with a rename on our object and rmdir on the old parent? I'm wondering if we need to be doing this test holding dentry->d_lock (whic= h is what protects dentry->d_parent if I recall correctly) Certainly doesn't fix all of the raciness, but I think it would close the opps part. Maybe someone who knows the VFS better can tell me if I am misguided. -Eric