Re: varlinks! (and 2.1.98 works for me)
Ton Hospel (thospel@mail.dma.be)
4 May 1998 00:45:58 GMT
In article <199805031450.QAA20706@lrcsun15.epfl.ch>,
Werner Almesberger <almesber@lrc.di.epfl.ch> writes:
> Ton Hospel wrote:
>> - stare at the link (e.g. do a readlink), do some checking, then follow it.
>> That had a race condition anyways, so it cannot be trusted
>
> Theoretically, it could do something like this:
>
> safety_t verify(path_list_t path_components)
> {
> while (path_components) {
> first = pop(path_components);
> if (is_directory(first) && is_trusted(first.owner) &&
> is_unwritable_for_untrusted_users(first.mode)) {
> advance_cwd(first);
> continue;
> }
> if (is_symlink(first)) {
> result = verify(read_link(first));
> if (result != SAFE) return result;
> continue;
> }
> if (is_file(first)) return SAFE;
> /* perhaps also allow certain other types */
> return UNSAFE;
> }
> return SAFE;
> }
>
> I think that, provided that we start with a trusted cwd or have an absolute
> path, and that trusted users don't change directory permissions on the fly,
> this leaves no races, but could be subverted by using varlinks.
>
> I don't know if this type of check occurs in real programs, though.
>
True, but if the link is driven by something that won't change from under this
code, varlinks are then in fact also safe (e.g. if the varlink translation is
driven by environment variables, or /proc entries only settable by the
user corresponding to the effective uid of this program). So given that extra
condition it still seems defendable to me that varlinks are security equivalent
to symlinks.
(also notice that in /proc we already have files where read_link sends us
somewhere different from follow_link, so in a sense we already have a case
worse than varlinks)
--
It takes forty men with their feet on the ground to support one man with
his head in the air.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu