On Mon, 04 Jun 2012 22:42:08 -0400 Eric Paris <eparis@xxxxxxxxxx> wrote: > > I really do not want to revert this and feel that the only right fix is > > going to be to update your selinux policy to allow this new check. I'd > > rather not allow (whatever program) to truncate() files willy-nilly (in > > violation of the intentions of selinux policy) > > > > I'm sorry I never saw it sooner. We've had it in RHEL for even longer > > than the 3 months it's been in -next. I think the 'right' fix is going > > to have to be an update to SELinux policy (for your long dead system, if > > you give me the denial I can build you a new policy) rather than leaving > > the potential security hole in mainline... > > Andrew sent me his audit log and it didn't show anything. But it got me > thinking. Now I think this actually is a code bug. Andrew, can you > test this? > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 2e7bd67..20a4315 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -2758,7 +2758,7 @@ static int selinux_inode_setattr(struct dentry *dentry, struct iattr *iattr) > ATTR_ATIME_SET | ATTR_MTIME_SET | ATTR_TIMES_SET)) > return dentry_has_perm(cred, dentry, FILE__SETATTR); > > - if (ia_valid & ATTR_SIZE) > + if ((ia_valid & ATTR_SIZE) && selinux_policycap_openperm) > av |= FILE__OPEN; > > return dentry_has_perm(cred, dentry, av); That fixed it. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
