[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC][PATCH] Inherit loginuid from parent



David Woodhouse <dwmw2 infradead org> wrote:

> It's been suggested that perhaps we could use the kernel's key
> management facilities for this. By attaching a key of a certain type to
> the session keyring, we get to set it _synchronously_, and we also have
> an unambiguous indication of its _absence_.

This facility has been in the vanilla Linux kernel since 2.6.10. See:

	Documentation/keys.txt

> David, can a process ever override its session keyring and elect to use
> another? That could be a problem -- this has to be immutable after it's
> set at login time, I believe.

Unfortunately, yes. There's a keyctl() op that allows a process to change the
session it belongs to.

However, since the key management stuff is not entirely graven in stone yet,
it can be extended. I can deal with the problem Dave mentioned by adding a
root-privileged keyring to each process that can't just be shuffled aside so
easily for the purpose of keeping track of auditing and security info of this
type. This keyring would be inherited across fork.

Either I can have it so that it is searched first, thus the search order would
become:

	Audit (or System, Security or whatever)
	Thread
	Process
	Session

Either that or it could just require explicit searching and not be on the
standard search path.

I'd make the "Audit" keyring owned by root, with modify privileges only for
root and stick keys of the type you'd be dealing with owned by root and only
modifyable by root so that the user can't change them. Furthermore, if you
don't provide an update method for the key type, then the keys are immutable
once instantiated.

David


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]