On 1/1/2014 7:20 AM, Joel Rees wrote:
On Wed, Jan 1, 2014 at 7:30 PM, Jerry Stuckle <drunkensot9...@gmail.com> wrote:
On 1/1/2014 2:52 AM, Joel Rees wrote:
[...]
On Wed, Jan 1, 2014 at 11:51 AM, Jerry Stuckle <jstuc...@attglobal.net>
wrote:
On 12/31/2013 8:43 PM, Joel Rees wrote:
On Wed, Jan 1, 2014 at 12:58 AM, Raffaele Morelli
<raffaele.more...@gmail.com> wrote:
[...]
I just want to add a (relevant) bit.
Apache has tons of directives to secure a website and if you really
need
to
upload in a dir you can tell apache to not execute php scripts in there
or
force file type to text or prevent POST request from untrusted ip, etc
etc.... and you'are done.
It has occurred to me on several occasions that apache is essentially
another shell over the underlying OS calls -- like bash is a shell for
character/command-line-oriented terminal (sessions).
No, Apache is a web server. It can load certain modules to provide
additional services, e.g. PHP or Python. But it is not a shell.
"Shell" has multiple meanings. Character-oriented command-line shell
is just one of them. (And I'm sure you know that.)
Yes, and "Web Server" is not one of those meanings.
Why not?
A web server exposes various aspects of the system to users, including
parts of the file system and parts of the ABI. That's basically what a
shell does.
No more than a text editor, word processor or spreadsheet does. The web
server takes a request from a user and returns the appropriate resource.
According to your definition, a spreadsheet is also a shell. So is an
editor.
Apache is a web server.
Nothing more, nothing less. It is not, and never has been, a shell.
And when has a web server not been a shell?
It never has been.
Sure, the division between user instances and the daemons that manage
the instances and keep the data moving between them and the external
world is a bit different. We usually forget that there is a daemon
keeping our shell instances running, where, with the web server, we
don't consider the shell and the daemon to be distinct.
But that's a problem of perception, not function.
Yes, and you have a perception problem.
Without additional modules, Apache can't even execute scripts.
What are you saying here? Why should a shell have to be able to
execute scripts if it can pass them off to appropriate interpreters?
And how does it fit with what you say below?
Because you seem to be basing your theory on the fact Apache can do
things other than return resources.
I suppose you might find some jargon dictionaries that insist that a
shell be a Turing complete programming language, but such dictionaries
are likely to claim that a graphical shell is fundamentally a
different thing from a shell. (Begging questions about scriptable
graphical shells.)
I never said any such thing.
But the
addition of scripting languages does NOT make it a shell.
So what does make a shell?
You tell me. You're the one trying to fit a square peg in a round hole.
If you aren't willing to use the term in the more complete meaning,
please stay out of the conversation. (And don't bother digging up
"definitions" that would eliminate purpose-specific-shells over the
ABIs or APIs, or I'll reach across the Pacific, grab my 30 year old
copy of the XINU text and throw it at you. ;-)
If you aren't willing to learn what Apache is and is not, please don't ask
the question.
Okay, so I just virtually threw my extra copy of the Apache manual at
you. Did you virtually duck?
(Now, if I were to send the apache documentation bundled as a pdf to
your e-mail address, that would be a pointless exercise in literal
throwing, not virtual, so I won't do that. :-/)
And where in the Apache documentation does it say it is a shell?
It has also occurred to me on several occasions that it implements its
own security model, and provides an alternate path into the system
resources (file system, etc.) that sometimes circumvents the native
security model.
Yes, it has some security features built in. But it cannot circumvent
the
native security model. If an application could do that, the security
model
in Debian would be worthless.
Yes and no, and if you would bother yourself to think beyond whatever
wall stands between you and me, I think you would not have said that.
You seem to have a problem with "whatever wall stands between you and me",
not me. I'm just trying to answer your question. But you are unwilling to
learn.
As in learn not to give you an excuse to flame the list?
If you want to flame me, you can do it in private, but of course that
would be less interesting to people watching me figure out why you're
wrong here. (And then again maybe no one is interested.)
You're the one who started with the "whatever wall..." bullshit. I just
took your question as a real one. Now I see it was only another excuse
for you to to argue something about which you know nothing.
I've been using web servers ever since IBM came out with one in the mid
90's (thankfully it's gone). I also used Lotus Domino server. I've
been running my own Apache and IIS web servers since the late 1990's or
so. NEVER have I heard anyone with any knowledge of webservers claim
they are shells.
I mean, in the parent thread to this, you laid out quite well the
problems of application support files being owned by root -- the
problem of who gets/has to edit them. You can see the larger issues if
you will.
Yes, and who can own the files has nothing to do with whether Apache is a
shell or not.
True, I was just commenting on the fact that you can sometimes say
quite reasonable and meaningful things. I suppose there's something
wrong with that?
To you, "reasonable" is "I agree with it".
And I note that I prefer the native Unix basic security model not to
be circumvented.
It cannot be.
If that were true, why would Apache (or any other web server) ever
have security advisories?
Because Apache has added additional security features to limit what people
can do from the web. These features are in addition to those of Linux (and
Windows), not a replacement for them.
Sure, it sometimes has issues with its implementation of separate
security models.
So does PostGresSQL. So does MySQL. So does the Java interpreter. In
fact, so does any non-trivial application which has security features.
But it doesn't mean the application has any back door past the OS's
security.
It also has had problems because of the practice it allowed (and used
to effectively encourage) of running as root or other privileged user.
That's a configuration issue, and the openBSD team did a good job of
demonstrating how to drop privileges after getting port 80, but it
provided a path to circumvent the system security model until it
became part of the standard server startup and configuration. (Still
some theoretical issues there.)
There have been a lot of security problems in applications in the past.
In fact, there have been problems in the Linux kernel in the past
which allowed non-privileged users to gain root privileges.
But that does not mean it is insecure today. And it does not mean it is
a shell.
Initial implementations of WebDAV had serious configuration issues, as
well, which we regularly have to revisit with Drupal and other such
packages.
So? The security issues still don't bypass the OS (or Apache) security.
Just because it has its own security issues has nothing to do with the
OS or Apache.
And there have been vulnerabilities in the past where the way it
exposed the file system ABI provided hard paths for privilege
escalation, literal circumvention of the *nix security model. There
will be again.
Please show where those vulnerabilities have existed and circumvent the
linux security model.
I have other thoughts on the subject, but my wife says we have to go
do the family new-year's stuff. Be interested in comments.
Learn how security works.
Jerry
That's not a comment I'm interested in.
Then don't ask the question.
Why? (And which question did you take offense at?)
You said you didn't want to hear the comment. If you don't want the
response, don't ask the question.
Jerry
Part of the problem with the disagreements about best practices for
configuring web servers, particularly those that expose a writable
path to the file system, is that we ignore the fact that the server
is, in effect, a shell.
We want to give it some special, superhero status that it is supposed
to do things that are fundamentally impossible, by virtue of it being
a web server instead of a shell. But that just leads us to take
shortcuts we shouldn't take -- like handling uploads as the same
system user as the daemon process that manages the entire server.
Maybe YOU do. But knowledgeable people don't. And just because you
screw up your implementation does not mean the web server can bypass
Linux security.
But I see this is just another excuse for you to argue rather than
learn. Forget the questions I asked above. Don't bother replying. I'm
not going to waste any more of my time.
Jerry
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c447be.9090...@attglobal.net
