linux-kernel - Re: [PATCH] utime(s): Honour CAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0707170306200.2005@cselinux1.cse.iitk.ac.in>
Date:	Tue, 17 Jul 2007 03:16:29 +0530 (IST)
From:	Satyam Sharma <ssatyam@....iitk.ac.in>
To:	Al Viro <viro@....linux.org.uk>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ulrich Drepper <drepper@...hat.com>
Subject: Re: [PATCH] utime(s): Honour CAP_FOWNER when times==NULL

On Mon, 16 Jul 2007, Al Viro wrote:
> On Tue, Jul 17, 2007 at 01:00:42AM +0530, Satyam Sharma wrote:
> > > 	if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER))
> > > 
> > > test is a rather common test, and in fact, arguably, every time you see 
> > > one part of it, you should probably see the other. Would it make sense to 
> > > make a helper inline function to do this, and replace all users? Doing a
> > > 
> > > 	git grep 'fsuid.*\<i_uid\>'
> > > 
> > > seems to show quite a few cases of this pattern..
> > 
> > Yes, I thought of writing a helper function for this myself. The semantics
> > of CAP_FOWNER sort of justify that, but probably better to get Al's views
> > on this first.
> 
> Helper makes sense (and most of these places will become its call), but...
> E.g. IIRC the change of UID requires CAP_CHOWN; CAP_FOWNER is not enough.
> Ditto for change of GID.  setlease() is using CAP_LEASE and that appears
> to be intentional (no idea what relevant standards say here)...
> 
> I'd suggest converting the obvious cases with new helper and taking the
> rest one-by-one after that.  Some of those might want CAP_FOWNER added,
> some not...

There aren't too many negative results, here's a little audit:

fs/attr.c:32:
fs/attr.c:38:

-> Both are from inode_change_ok(). [ for chown(2) and chgrp(2) ]
-> CAP_FOWNER is not checked for either case, I think it should be.
-> CAP_CHOWN is anyway checked for explicitly later in that condition.

fs/namei.c:186: if (current->fsuid == inode->i_uid)

-> generic_permission().
-> I wonder if CAP_FOWNER processes should ever even be calling into
   this function in the first place (?)
-> So best to keep CAP_FOWNER out of this condition (?)

fs/namei.c:438: if (current->fsuid == inode->i_uid)

-> exec_permission_lite().
-> This is a clone function of the previous one, so again CAP_FOWNER
   out of this (?)

fs/reiserfs/ioctl.c:54:
fs/xattr.c:63:
-> False positives, CAP_FOWNER checked on line below.
-> Helper would help for both cases.

Anwyay, so I'm thinking of adding:

struct inode;

int is_not_owner(struct inode *)
{
	return ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER));
}

to linux/capability.h inside the __KERNEL__ #ifdef, asm/current.h is
included in there already.

And then do the necessary conversions. Sounds OK?

Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/