Hi! > > On Wed 2018-01-24 09:37:05, Dominik Brodowski wrote: > > > On Wed, Jan 24, 2018 at 07:29:53AM +0100, Martin Schwidefsky wrote: > > > > On Tue, 23 Jan 2018 18:07:19 +0100 > > > > Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > On Tue, Jan 23, 2018 at 02:07:01PM +0100, Martin Schwidefsky wrote: > > > Well, partly. It may be that s390 and its use cases are special -- but as I > > > understand it, this uapi question goes beyond this question: > > > > > > To my understanding, Linux traditionally tried to aim for the security goal > > > of avoiding information leaks *between* users[+], probably even between > > > processes of the same user. It wasn't a guarantee, and there always > > > > It used to be guarantee. It still is, on non-buggy CPUs. > > In a perfect world none of this would have ever happened. > But reality begs to differ. Ok, so: "Linux traditionally guarantees lack of information leaks between PIDs". Yes, you can use ptrace, but that should be it. > > Leaks between users need to be prevented. > > > > Leaks between one user should be prevented, too. There are various > > ways to restrict the user these days, and for example sandboxed > > chromium process should not be able to read my ~/.ssh. > > Interesting that you mention the use case of a sandboxed browser process. > Why do you sandbox it in the first place? Because your do not trust it > as it might download malicious java-script code which uses some form of > attack to read the content of your ~/.ssh files. That is the use case for > the new prctl, limit this piece of code you *identified* as > untrusted. See Alan Cox's replies. Anyway. There's more than one way to mark process as untrusted, (setuid nobody, seccomp, chroot nowhere, ptrace jail, ...). Do not attempt to add prctl() to the list. > > > In recent days however, the outlook on this issue seems to have shifted: > > > > > > - Your proposal would mean to trust all userspace code, unless it is > > > specifically marked as untrusted. As I understand it, this would mean that > > > by default, spectre isn't fully mitigated cross-user and cross-process, > > > though the kernel could. And rogue user-run code may make use of that, > > > unless it is run with a special wrapper. > > > > Yeah, well, that proposal does not fly, then. > > It does not fly as a solution for the general case if cross-process attacks. > But for the special case where you can identify all of the potential untrusted > code in your setup it should work just fine, no? Well.. you can identify all of the untrusted code. Anything that does not have CAP_HW_ACCESS is untrusted :-). Anyway, no need to add prctl(), if A can ptrace B and B can ptrace A, leaking info between them should not be a big deal. You can probably find existing macros doing neccessary checks. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
