Stas Sergeev wrote:
>Ulrich Drepper wrote:
>>> Now, as the access(X_OK) is fixed, would it be
>>> feasible for ld.so to start using it?
>> Just must be kidding. No access control can be reliably implemented at
>> userlevel. There is no point starting something as stupid as this.
>But in this case how can you ever solve the
>problem of ld.so executing the binaries for which
>the user does not have an exec permission?
By using the kernel's existing access control -- not trying to roll
your own access control at the user level. This is a standard recommendation
in the security world, and it is good advice.
For instance, in this case, this advice might mean that you just call
execve() and check whether it succeeded or failed, and let the kernel
do the access control check on whether the exec is permitted. That tends
to be more fool-proof (or at least fool-resistant) than the alternatives.
>Yes, the userspace apps usually should not enforce
>the kernel's access control, but ld.so seems to be
>the special case - it is a kernel helper after all,
>so it have to be carefull and check what it does.
Perhaps. But it seems to me that there would need to be a persuasive
argument before it makes sense to violate the general advice listed above.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
