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: <20070926180858.GP8181@ftp.linux.org.uk>
Date:	Wed, 26 Sep 2007 19:08:58 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	David Howells <dhowells@...hat.com>
Cc:	hch@...radead.org, Trond.Myklebust@...app.com, sds@...ho.nsa.gov,
	casey@...aufler-ca.com, linux-kernel@...r.kernel.org,
	selinux@...ho.nsa.gov, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 01/24] CRED: Introduce a COW credentials record

On Wed, Sep 26, 2007 at 03:21:05PM +0100, David Howells wrote:
> To alter the credentials record, a copy must be made.  This copy may then be
> altered and then the pointer in the task_struct redirected to it.  From that
> point on the new record should be considered immutable.

Umm...  Perhaps a better primitive would be "make sure that our cred is
not shared with anybody, creating a copy and redirecting reference to
it if needed".

 
> In addition, the default setting of i_uid and i_gid to fsuid and fsgid has been
> moved from the callers of new_inode() into new_inode() itself.

I don't think it's safe; better do something trivial like
	own_inode(inode)
that would set these (and that's a goot splitup candidate, to go in front
of the series).


FWIW, the main weakness here is the need of update_current_cred()
splattered all over the entry points.  Two problems:
	a) it's a bug source (somebody adds a syscall and forgets to
add that call / somebody modifies syscall guts and doesn't notice that
it needs to be added).
	b) it's almost always doing noting, so being lazier would be
better (event numbers checked in the inlined part, perhaps?)


The former would be more robust if it had been closer to the places where
we get to passing current->cred to functions.  The latter...  When do
we actually step into this kind of situation (somebody changing keys on
us) and what's the right semantics here?  E.g. if it happens in the middle
of long read(), do we want to keep using the original keys?

Comments?
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ