linux-kernel - Re: C/R review

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: <49C0C273.4070408@cs.columbia.edu>
Date:	Wed, 18 Mar 2009 05:44:19 -0400
From:	Oren Laadan <orenl@...columbia.edu>
To:	"Serge E. Hallyn" <serue@...ibm.com>
CC:	Alexey Dobriyan <adobriyan@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Linux Containers <containers@...ts.osdl.org>
Subject: Re: C/R review



Serge E. Hallyn wrote:
> Quoting Alexey Dobriyan (adobriyan@...il.com):
>>> +Keeping the restart procedure to operate within the limits of the
>>> +caller's credentials means that there various scenarios that cannot
>>> +be supported. For instance, a setuid program that opened a protected
>>> +log file and then dropped privileges will fail the restart, because
>>> +the user won't have enough credentials to reopen the file.
>> That's a bug.
> 
> What is described is not a bug, but I think the way it is done is in
> fact a bug.
> 
> Note that just because you *can* do the restart without privilege
> doesn't mean that you have to.  If you do a restart with privilege,
> then you should be able to open that file, then drop down to the
> original task's uid.
> 
> But to say that letting an unprivileged user do restart, and that
> it will only succeed if it can access the resources its allowed to
> access, is bogus.
> 
> But I do think the way it's implemented will become buggy and needs to
> be fixed.  That is, we do cr_read_task_struct() before we do
> cr_read_files().  So in fact if I'm root doing restart of such a
> checkpoint image, I'll first drop down to uid 500, then open the files.
> 
> That would obviously be a bug.
> 
> Now, we don't actually restore uids yet in the current code, so
> it's still a theoretical bug :)

Good point. And that's why uid's will be restored at the end :)
(when we get there ...)

Oren.
--
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/