Mailing List Archive

I see little value in the new directive. Either you allow symbolic
links and know the consequences (document it) or you don't. This
is creaping featurism. I don't think we need this.

Cliff

From: cliffs@steam.com (Cliff Skolnick)
Date: Mon, 17 Apr 1995 22:00:56 PST

I see little value in the new directive. Either you allow symbolic
links and know the consequences (document it) or you don't. This
is creaping featurism. I don't think we need this.

The value is the elimination of a serious misfeature --- people who
use the automounter, and who want to enable UserDirs, and *disable*
FollowSymLinks, currently can't, because the entries in the
automounter's pseudo-directories appear as symlinks owned by root.

(To spell it out, when a client requests /~foo, that turns into
/home/amdir/foo, where /home is automounted directory. The server
looks at /home/amdir, sees it's a symlink (to /tmp_mnt/home/amdir),
and bounces the request).

Allowing symlinks owned by the owner, *or root*, to pass the cut in
FollowSymOwner provides a tolerable middle ground, and people who are
really concerned about security can always disable the option.

rst

This is now B77.

It can go to the vote.

Hi, everybody!
> I see little value in the new directive. Either you allow symbolic
> links and know the consequences (document it) or you don't. This
> is creaping featurism. I don't think we need this.
>
> The value is the elimination of a serious misfeature --- people who
> use the automounter, and who want to enable UserDirs, and *disable*
> FollowSymLinks, currently can't, because the entries in the
> automounter's pseudo-directories appear as symlinks owned by root.
>
> (To spell it out, when a client requests /~foo, that turns into
> /home/amdir/foo, where /home is automounted directory. The server
> looks at /home/amdir, sees it's a symlink (to /tmp_mnt/home/amdir),
> and bounces the request).
I feel it's right time to promote my patch (see below) I was invited to
this list for. To refresh your memory it was eliminating redundant
.htaccess searches on the path to a document subtree, e.g.: request for
/~foo checks .htaccess only in /home/amdir/foo/public_html instead of
going through the whole directory chain starting from /.htaccess. I am
saving a lot of CPU cycles in my place by avoiding hitting non-existing
/home/.htaccess, which is causing automounter attempt, which in turn
involves NIS+, etc.. Well, it looks like it would fix the
"impossibility to allow automounted UserDirs AND to disable
FollowSymLinks" problem as well! And indeed it would never look into
/home and won't ever find out there're links... Then it's no
problem to prohibit to follow symlinks in UserDirs by adding
"<Directory /home>\nOptions None\n</Directory>" statement to
access.conf, right? Unfortunately I can't check it out in action,
because I run Solaris 2 and /home/* are real mount point, not
symlinks.

Sincerely yours. Andy.

P.S. Patch is relative to 0.6.1.
------------------------------cut here---------------------------------
*** ./http_access.c.orig Sat Apr 15 20:05:38 1995
--- ./http_access.c Tue Apr 18 19:40:11 1995
***************
*** 197,203 ****
if((override[n]) || (!(opts[n] & OPT_SYM_LINKS)) ||
(opts[n] & OPT_SYM_OWNER))
{
! for(x=0;x<num_dirs;x++) {
y = num_sec;
make_dirstr(path,x+1,d);
if((!(opts[x] & OPT_SYM_LINKS)) || (opts[x] & OPT_SYM_OWNER)) {
--- 197,204 ----
if((override[n]) || (!(opts[n] & OPT_SYM_LINKS)) ||
(opts[n] & OPT_SYM_OWNER))
{
! vvvvvvvvvvvvvvvvv-- eliminate redundant checks
! for(x=tackle_on_docroot(path);x<num_dirs;x++) {
y = num_sec;
make_dirstr(path,x+1,d);
if((!(opts[x] & OPT_SYM_LINKS)) || (opts[x] & OPT_SYM_OWNER)) {
*** ./http_alias.c.orig Sun Apr 16 22:28:23 1995
--- ./http_alias.c Mon Apr 17 17:52:18 1995
***************
*** 248,250 ****
--- 248,265 ----
}
}
}
+
+ int tackle_on_docroot(char *name) {
+ register int x,l;
+ alias *p;
+
+ l=strlen(document_root);
+ if(!strncmp(name,document_root,l))
+ return count_dirs(document_root);
+ for(p=a; p!=NULL; p=p->next) {
+ l=strlen(p->real);
+ if(!strncmp(name,p->real,l))
+ return count_dirs(p->real);
+ }
+ return 0;
+ }

On Apr 18, 9:41am, Robert S. Thau wrote:
}
} (To spell it out, when a client requests /~foo, that turns into
} /home/amdir/foo, where /home is automounted directory. The server
} looks at /home/amdir, sees it's a symlink (to /tmp_mnt/home/amdir),
} and bounces the request).
}-- End of excerpt from Robert S. Thau

The new automounter uses "autofs" and does not do this, but yes I
agree there is a significant number of old automounters out thre
so I will continue.

Most security concious companies have a firewall and set the web server up
outside said firewall. They do not run any automounter. So in
this case there is not a problem.

The other end is the internal web site where people are trusted. Again,
not a problem.

So what if your users are not trusted? How many of these sites
where users are not trusted even run the automouter? I think
it's foolish when the person can just "cp /etc/passwd myfile.txt"
to think that not allowing "ln -s /etc/passwd myfile.txt" will add
ANY security. I just don't see this as solving a real problem for
a number of people. Maybe a couple, but not a large number.

Cliff

-1 on B77

Even though I am against B77, I would be for disallowing symlinks on
a directory by directory basis. I think that is a better and more
general solution.

Cliff

On Apr 18, 4:27pm, Robert S. Thau wrote:
} So what if your users are not trusted? How many of these sites
} where users are not trusted even run the automouter?
}
} Probably most of them --- the ones I'm aware of are generally
} universities, which need some automounter-like system to coordinate
} among multiple, large, group fileservers.

Well...I shoudl say how many of these system that also are web servers
run the automounter. I know a few universities will fall into this
catagory, but no company I have ever seen. I deal quite a bit with
internet security and have seen lots of companies.

} So you think that FollowSymLinks (or rather, the ability to turn it
} off) is silly, and you don't want to make it useful for people because
} you don't see the point of having it in the first place. People who
} are using it (or want to) evidently disagree.


No,I'm saying the ability to follow a symlink only sometimes is silly.
Either you allow them (trust) or you don't (don't trust). I am
saying we don't need a middle ground config option. Do it directory
by directory with existing mechanisms.


}
} (This is separate from the argument of whether root-allowed symlinks
} is the best thing, or whether we want something more like Andy
} Polyakov's patch --- note that Andy's is also a performance win, since
} it avoids some checks which are really unnecessary on most systems,
} although I can see a Paranoid config directive for people who have
} setups who depend on the old behavior...).

I'm all for perfomance wins :), but I am against creeping featurism.
Apache can not be everything to everybody. It will die if it tries.
No one wants to use a monster (ie CERN).

If we want to fix the security problems, we'll do up a server that
uses chroot(). That is a much better solution than a bunch of hacks
and imposible to rememeber/use options.

Cliff

From: cliffs@steam.com (Cliff Skolnick)
Date: Tue, 18 Apr 1995 11:55:17 PST

So what if your users are not trusted? How many of these sites
where users are not trusted even run the automouter?

Probably most of them --- the ones I'm aware of are generally
universities, which need some automounter-like system to coordinate
among multiple, large, group fileservers.

I think
it's foolish when the person can just "cp /etc/passwd myfile.txt"
to think that not allowing "ln -s /etc/passwd myfile.txt" will add
ANY security. I just don't see this as solving a real problem for
a number of people. Maybe a couple, but not a large number.

So you think that FollowSymLinks (or rather, the ability to turn it
off) is silly, and you don't want to make it useful for people because
you don't see the point of having it in the first place. People who
are using it (or want to) evidently disagree.

(This is separate from the argument of whether root-allowed symlinks
is the best thing, or whether we want something more like Andy
Polyakov's patch --- note that Andy's is also a performance win, since
it avoids some checks which are really unnecessary on most systems,
although I can see a Paranoid config directive for people who have
setups who depend on the old behavior...).

rst

From: cliffs@steam.com (Cliff Skolnick)
Date: Tue, 18 Apr 1995 12:10:23 PST
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

Even though I am against B77, I would be for disallowing symlinks on
a directory by directory basis. I think that is a better and more
general solution.

Cliff

You can already do this --- Options FollowSymLinks (or not). I don't
think that's the issue addressed by B77; if you do have a way to use
selective Options FollowSymlinks to make it possible to disable it for
UserDirs which are accessed through the autmounter, a whole *lot* of
people would be interested.

rst

> No,I'm saying the ability to follow a symlink only sometimes is silly.
> Either you allow them (trust) or you don't (don't trust). I am
> saying we don't need a middle ground config option. Do it directory
> by directory with existing mechanisms.

That would be nuts. I have control over my server's documentroot
directories, and thus I can safely allow all SymLinks there. In contrast,
I have no control over user directories (and don't trust my users),
and thus cannot allow arbitrary SymLinks. I use

<Directory /dc/ud/www/documentroot>
AllowOverride FileInfo AuthConfig Limit
Options Indexes FollowSymLinks IncludesNoExec
</Directory>

<Directory /*/public_html*>
AllowOverride FileInfo AuthConfig Limit
Options Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory>

to allow this feature. Removing it from Apache would break Apache.

We also use an automounter, but one that does not (normally) symlink
the mounts -- those few users that get symlinked are not able to
use their public_html spaces. I consider both of the proposed patches
to be desirable.

> If we want to fix the security problems, we'll do up a server that
> uses chroot(). That is a much better solution than a bunch of hacks
> and imposible to rememeber/use options.

No it isn't -- such a server cannot work in my environment.

.....Roy
584 messages down, 1110 to go

I've seen alot of people trying to add a bit of security for
both symlinks and the running of CGI scripts. Each proposal adds
a little security of which few really protect anything from a
malicious user.

For example, follow sylinks if only if owner. People were worried
about someone placing a symlink to /etc/passwd or some other file
you don't want just anyone to see. What would stop a malicious user
from simply using cp to copy the file and distribute it that way?
Seems like an admins would be fooling theselves to me. Now a
follow sylink only if owned by root might make sense to me. I just
don't see why we should trust a user's symlinks any less than we
trust his files. I forgot who pointed the fact that ~user expansions
on hosts with an older (the newer automounter uses autofs) required
symlinks be turned on. Some mechanism to allow the symlinks under
/home, but no others is needed, so maybe this is an ok thing.

I also have seen discussion about CGI security and log files, which
still confuses me a bit. I still think if you don't trust a user
to be "good", then you should not let them install cgi's. None
the less closeing log files upon exec would be a good thing if
we combined it with a chroot'ed enviornment for the execution of
a cgi. So we are half the way to a real solution. If a "caged"
enviornment, you may be willing to trust someone you would not
otherwise.

I think at some point when the program is overhauled we can look
at memory allocation. That is something that will keep biting us
since one gets plugged, and more stack corruption bugs are found.

Cliff