At 04:25 PM 2/23/2001 -0500, wiz wrote:
> I agree about the CGI stuff, as the username should always be the same
>anyway, so it can be defined separately for that user. I do believe that we
>need to at least take CGI scripts into account, however.
I think if we take CGI scripts specifically into account we're doing things
wrong. Whatever model we choose should handle CGI code properly because the
model is correct, not because it's the target of the model.
> Some questions:
>1.> you wrote: "Generally speaking we ought to have the capability to use or
>not use any of the opcodes" - I'm not entirely sure what you mean by this.
>Are you saying that the admin should have the ability to limit this, or the
>developer/user (or not at all)?
Yes. We can do this with Safe now--particular opcodes (usually the ones
dealing with files, eval, and suchlike things) can be enabled or disabled.
>2.> What do you mean by 'crockable'(I've never heard the term)?
> Some comments:
Can be subverted, crocked, broken, or otherwise rendered useless.
>1.> "Content-Length", although CGI-specific, is a big hole. It probably
>should be handled by the webserver, but it isn't, and almost none of the
>scripts that I have encountered check it before reading. I realize that
>it's not 'Perl's fault', but why purposely leave a hole open?
Why wedge into perl something that's not specifically a perl issue? If you
want to put quotas on files that's fine, but that's something that should
be done at the OS level. Granted we've worked around OS flaws before, and
will certainly do so again, but even with that in mind you're being far too
specific.
And, frankly, if a webserver doesn't have the capability of limiting
resource usage by clients, it's broken. If it has them but they're not
used, then having them in perl won't help, since if they're not set up in
the server (where they belong) why on earth should we assume they'll be set
for perl?
> As far as the suggestions being primitive, you're right. They are really
>just some thoughts that have been voiced, and it's only intended to get
>people talking about it. Even still, it's miles ahead of what we have now
>;). As time allows, I will make every effort to look into other security
>models and try to patch together some general idea of what this thing
>should do (I hope others will, too), and maybe how it should do it. I'm
>not a security guru by any stretch, and don't expect to be one anytime soon.
I wasn't trying to scare you off or anything. I was trying to make sure we
didn't go off in directions I know are wrong or too targeted. I'm not a
security expert myself, but I've wrangled the big boxes and I'm familiar
with this stuff at an admin level.
> If you have any suggestions as to where you think it should move, or
> perhaps even some existing models that you like, please let me know, and
> I'll take a look. In all honesty, it might be better left to a security
> expert, but I'll be happy to struggle through until one comes along.
Well, the VMS doc I posted a pointer to is a good one, since VMS provides
these features (CPU and memory limits, reasonably fine-grained access
controls on system level things, as well as files). If you can scare up a
copy of the Orange Book (I think) and see what's involved in C and B level
security you might want to do that.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
