>> Suggested rules:
>>
>> 1. Always allow 32-bit calls.
>>
>> 2. Always have 16-bit calls in the kernel. (see below)
>>
>> 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.
>>
>> 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.
>
> Hmm, altough I'm fully aware of these points being restricted to UID
> issues, it is very reminiscent of the win16->win32 transition and all
> its pain (& overhead). Esp. items 4-6 seem rather ugly to me. Was this
> meant to be a temporary workaround - maybe introduced in 2.3/2.4 and
> then 2.6/3.0 support only 32bit-UID - or do such things become legacy
> ballast until a 'Linux NT' is written from scratch to remove all of
> this?
After transition, points 5 and 6 are no overhead. (they only affect
the use of old calls) Point 4 is a tiny bit of overhead for the
detection of large UID values, but that can be eliminated at some
point: just assume they will be used, so all privileged processes
must use the new calls unless allowed by point 6.
-
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/