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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 17 Mar 2009 19:47:42 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	orenl@...columbia.edu, lkml <linux-kernel@...r.kernel.org>,
	Linux Containers <containers@...ts.osdl.org>
Subject: Re: C/R review

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 :)

-serge
--
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