Mailing List Archive

> > There are sites which use a setuid-root "wrapper" program so that a user's
> > CGI scripts may run with the user's *own* full privileges --- but that's
> > also a somewhat dangerous practice.
>
> Ah perhaps that's what COMMA are doing. Everyone's in bed right now so
> I'll have to wait till tomorrow to get Robert Evans' answer. Unless Rob H
> can remember?

I'll try...

The server runs as user "htbin" - yeah, not a good name, but that's
what we're stuck with (we got involved with www at an early stage).
Trusted CGI is run as user "htbin".

User's CGI scripts are run as a different user, with another daft name,
but this one I can't remember, let's call it "nopriv"

"nopriv" has fewer privileges than "htbin". I think it's also restricted
to the user's cgi directory, so it can't go off broadcasting the contents
of anything outside of this directory.

"htbin" has certain privileges in that it has write access to
some directories and log files that the trusted CGI scripts use.
It also has full access to anything that the world can read. So a
trusted CGI script could read /etc/passwd if it needed to.


robh

> "nopriv" has fewer privileges than "htbin". I think it's also restricted
> to the user's cgi directory, so it can't go off broadcasting the contents
> of anything outside of this directory.

this is why I suggested the CGI on but CMD off switch for includes.
At the moment the security at Cardiff relies on
none of the untrusted users getting wise enough to write
security flawed scripts as includes.

XBITHACK is switched on everywhere at Cardiff.. I doubt if the
sys admin realises the hole is there.

We've grown to rely on XBITHACK, and do need to execute included
scripts at times. The problem is that we're now back to an all or
nothing setup :-(


robh

We'll have to chat with Robert Evans to see what holes he's plugged
and how he's plugged them. I don't know how the system works, and I
don't use it myself - for some unknown reason, he still trusts me with
common or garden CGI :-)

> [ ... scratches head ... ]
>
> ... the flaw being that allowing them <!--#exec cgi--> (which is
> reasonably safe, as it only allows CGI scripts which the client could
> have caused to be invoked directly) *also* allows them to use an
> <!--#exec cmd--> (anything, anyhow, anywhere).
>
> Hmmm...

That's it. The untrusted, unwashed masses get to run their scritps
as the same user that the trusted CGI scritps uses - so some bozzo can
trash the movie db cache directory and any other useful files we use
to keep things running smoothly, just by writing himself a html page
with an included "cmd".

Allowing users to write their own CGI scripts certainly does pose problems
(the most significant of which have to do with the users themselves --- you
need to have confidence in their competence and good faith). However, I'm
not quite sure what this "wrapper" you're talking about would accomplish.

The server itself ordinarly does a setuid(nobody) before even determining
whether a script will be involved in servicing the request or not (or rather,
a setuid() to whatever is specified in the User directive), so it wouldn't
subsequently even have privilege to setuid() to some other ID. About the
only way I can think of that this "wrapper" would have an effect is if
httpd.conf specifies "User root" (so that the "wrapper" would have privilege
to do the setuid() itself) --- and "User root" is most certainly a very bad
idea.

There are sites which use a setuid-root "wrapper" program so that a user's
CGI scripts may run with the user's *own* full privileges --- but that's
also a somewhat dangerous practice.

rst

Depending on your Joe.Users, some of them very well might have malicious
intent (American undergrads are famous for this), and whatever policies
a local site has should take this into account. Aside from this, the
major security concern is, say, Joe.User writing a script in shell because
it's something he knows, without taking the *extreme* care you need to
keep requests which include shell metacharacters from handing a potential
attacker the keys to the kingdom.

(An early version of a fairly widely-distributed archie-gateway CGI script
was written in shell. I was able to fabricate a request to this thing
which would give me an xterm running on the server --- I only used this on
my own machine, of course, and mainly as incentive to rewrite the version
of the thing running locally in Perl).

rst

Ah... interesting setup. If they're running AFS, I can see how something
like this might be nice; however, if they aren't, I have a little trouble
figuring out how it would work. (On most Unix boxes, it's really hard
to take away the privilege to read a world-readable file, regardless of
its location --- AFS does change this a bit).

I can see how something like this would be of real use to those with serious
security concerns (as might other things, like some gestures toward chroot
support). Just so long as it really is an option for most of them...

(BTW, how does the COMMA setup deal with shared libraries? Does "nopriv"
have privilege to access them as well, or are all user scripts linked
statically?)

rst

From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Mon, 17 Apr 95 16:28:47 MDT

this is why I suggested the CGI on but CMD off switch for includes.
At the moment the security at Cardiff relies on
none of the untrusted users getting wise enough to write
security flawed scripts as includes.

XBITHACK is switched on everywhere at Cardiff.. I doubt if the
sys admin realises the hole is there.

[ ... scratches head ... ]

... the flaw being that allowing them <!--#exec cgi--> (which is
reasonably safe, as it only allows CGI scripts which the client could
have caused to be invoked directly) *also* allows them to use an
<!--#exec cmd--> (anything, anyhow, anywhere).

Hmmm...

rst

> There are sites which use a setuid-root "wrapper" program so that a user's
> CGI scripts may run with the user's *own* full privileges --- but that's
> also a somewhat dangerous practice.

Ah perhaps that's what COMMA are doing. Everyone's in bed right now so
I'll have to wait till tomorrow to get Robert Evans' answer. Unless Rob H
can remember?

> rst
>

Incidentally is this danderous in the sense of Joe.User writing a
script to fork a million processes and hang the server? Or writing some
script which fills up the filesystem.

[.in which case you shouldn't even give your users access to 'cc' ;)]

Or is there a more general security issue, like being able to read .passwd
files or whatever due to misplaced permissions.

Ay.