Re: Privilege Levels Below User

On Mon, 10 Jun 2024 18:43:09 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

John Savard wrote:
>

On Sun, 9 Jun 2024 22:48:28 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

>

And just as a further nitpick (if the above weren?t enough), what
happens
 
if the ?file? your C compiler is writing to is in a RAM disk?

>

Well, the output could be stored with no problem, because while it's
on the RAM disk, it can't be executed. It has to be copied from the
RAM disk, into memory that's not pretending to be a disk, by the
loader. So this case doesn't change anything from the case of a real
disk.

>
One can create a PTE pointing at that RAM disk page and then allow
someone to execute it directly.
OR
One can copy it somewhere that has execute permission in a single
instruction (MM = memory to memory move)
>
Neither is any real burden to enabling execute.

I'm not claiming that locating code in a RAM disk would _prevent_ a
program from enabling its execution. Normally, though, that wouldn't
be done just because it would mess things up for the software that is
supposed to be in charge of reading and writing from the RAM disk if
anything else accessies it.

My point was entirely different. Just as a JIT compiler doesn't run
into issues because it writes code to memory, but because it writes
code to memory with the intent of executing it later - and enabling
both write and execute is restricted in the case of the sort of
security-focused system we're discussing - an ordinary compiler
writing to a RAM disk instead of a physical disk runs into no issues.

Writing code in memory is not an issue. Write can be enabled to
memory. Only enabling write and execute together is potentially
subject to restricions.

So the idea of a RAM disk doesn't change anything.

John Savard