[Cryptography] Usable Security Based On Sufficient Endpoint-Specific Unpredictability

[Ralf Senderek]

On Sun, 11 Oct 2015 Ray Dillinger writes:

> The point is that the malware is already executing (as the
> user); it doesn't need to get root execute privileges if
> it has root read privileges.

I believe firmly that this conclusion is false.

> If the malware can read with root privilege then it can read
> executable code with root privilege.

Of course.

> And if it can read
> executable code with root privilege, and it is already executing,
> then it can execute that code, if in no other way, then by
> using, eg, a Bochs machine or the equivalent built into
> the malware.

Sure, but the execution would be under the users UID with access
permissions to files under the same UID.

> What it comes down to is that you can't rely on execute
> privilege alone to protect secrets.

I believe I can rely exclusively on execute privilege (UID=0)
if my analysis of the problem is not flawed and there isn't a
shortcut I cannot see yet.

> For example, if
> execution of some program as root can give the number 54,
> then any process that has root-level read privileges can
> perform the computation to get that number,

Not at all! Because if 54 is the inode number of the file
in question, then running the machine code that hides behind
"ls -i filename" will produce this number and no file content
will reveal the information to calculate this number. [1]


> whether they
> run the computation as root or as some other user.

My assumption is, that the input necessary to perform this
calculation (as root or user) is not available as the content
of a file. [1]

In the old days you could inspect the data block of a directory
with cat. That would reveal the file allocation table of the
directory with the inodes and starting data block, access permissions
and filenames. But in modern unix-like OSes (some? all?) the kernel
code prevents you from inspecting the directory data block which is
a good thing (TM) with respect to the solution I propose, because it
forces you to run the inode calculation code as UID=0 in the kernel.

Thanks for advancing the discussion of the crucial point.

        --ralf


[1] There is one obvious counter-argument, though. The special device
file /dev/sda13 is readable by root and if the malware can trick some
root process to read it and stream the whole raw filesystem to the
malware user. Reading this stream would "somewhere" reveal the bits
of information that make up the input of the userland computiation
mentioned by Ray above. But that's giving the haystack and asking
for the needle, to be found without running kernel code as root.