Thanks for writing back-- I thought about these same things when I first
wrote the patch...
> Suggested rules:
> 3. Let unprivileged processes get garbage UID values. The software
> isn't very dangerous, and it might work fine.
>
> 4. If any large UID is ever set for any process, privileged processes
> must not be allowed to make any 16-bit calls. Log the problem,
> stop the process, and return failure if the process continues.
>
I thought about doing something like this, but I think it would end up
being more overhead than it is worth. I don't think that it is
unreasonable to say "don't run any old statically linked binaries as root
if you have more than 65,535 users". Anyway, this approach can't catch all
problems- what if someone's code uses a short int internally but is linked
against glibc?
> 5. Have a run-time config option to kill any privileged process that
> tries to use a 16-bit call.
>
> 6. Have a run-time config option to allow 16-bit calls from privileged
> processes that are not setuid.
Again, when/if 32-bit UIDs become standard in Linux, I don't think _any_
of the typical distributions would include any programs intended to be run
as root that are not linked against glibc.
Thanks,
Chris Wing
wingc@engin.umich.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/