On Thu, Jan 2, 2014 at 1:52 AM, Jerry Stuckle <jstuc...@attglobal.net> wrote: > 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.
Well, yeah. And? I'm sure you'll take exception to referencing wikipedia, but I will anyway. http://en.wikipedia.org/wiki/Shell_%28computing%29 Now, there's a lot in there that would support your reference to the prevailing use of the word, but there's a lot in there that would not support your insistence on restricting the term to a shell that provides a command line interface. We don't need to actually bat quotes around, do we? >>> 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. Well, it's too bad I don't have my copies of the ACM IEEE journals from sometime in the '80s when I subscribed, because there were sure diagrams in several of those that showed that basically any wrapper for OS functionality or resources should be viewed as a shell, and accompanying articles that mentioned command shells and graphical shells as two instances of the general class, and specifically included applications as "higher level" wrappers around the OS. Various kinds of general purpose servers were specifically included as shells, as well. Jests about reaching across the Pacific aside, they are on the other side of the ocean. And I am not interested in spending money on PDFs of the articles just to satisfy your demands. >> 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. Touche. But completely irrelevant. >>> 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. And? Considering that resources can be access to functioning instances of programs, how does restricting web servers to returning resources restrict one from viewing a server as a shell? You aren't, I assume, going to claim that command line shells never 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. I never said you did. I did compare your attempts to assert that we must never attempt to view or understand the web server as if it were a shell to attempts to restrict the word to command line shells. It's a limit on your vision. >>> 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. I am telling you and you are calling me names instead of considering the definition, much less checking the alternative perspective for usefulness. I don't care whether you find the concept useless or not, BTW. Your quibbles can be used to describe parts of the view, even if you aren't interested. >>>> 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? Apache documentation is not written in the abstract, and I assume you will argue that I'm making too much of the reference, but http://httpd.apache.org/docs/2.2/howto/cgi.html.en notes that apache works like *nix shells in recognizing the interpreter declaration on the first line of a script. >>>>>> 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. Does that really help the conversation? > 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've been using web servers for a bit longer than you. Picked up Apache just a little after they named it for being a patchy mess. So what? Except for this, I remember that back then, the purpose was specifically to provide a shell to the network that would provide an alternative view to the file system, as an applied instance of providing alternate paths to a restricted set of the system resources. I remember when Apache still responded to things like "http://../bin/sh";, and the short discussion of whether that wasn't something you might want to allow. >>>> 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? Wait a minute. I let you trap me into that? How careless of me. That was a significant part of the reason why I wanted to talk about the similarities between the command line shell and web servers, including apache. If you aren't careful with how you set up the OS ownership and permissions, a web server can provide a random user from the network with effective ownership of files they shouldn't have access to. You have to use both the access controls that apache provides _and_ the access controls that the system provides, to keep the resources on the system secure. Maybe I'm reading too much into people's laziness, but the tenor of the conversation leads me to suspect that many people do not understand that web servers have certain things in common with shells, and if you misuse them they give access. And you're trying to turn the conversation into a quibble about the definition of "shell". > To you, "reasonable" is "I agree with it". Again, that doesn't help anyone understand anything. >>>>>> 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. The PostGreSQL client definitely presents a user shell. Not to the whole system, but to the part of it managed by the PostGreSQL server. > So does MySQL. Ditto. I'm sure you remember those diagrams which presented the kernel as a ball surrounding the hardware, with various ABIs (APIs, back then) wrapping --providing a "shell" around the kernel, with the command-line shell providing another (partial) "shell" layer and the GUI providing a separate shell, and various servers as yet further layers. Most layers do not completely cover the underlying layers, some reach below the layers immediately below, etc. The "shell" metaphor has issues, but so does the "wrapper" metaphor. Even in the usually accepted case of the command-line shell and the graphical UI shell, the metaphor is not a perfect match. But it's still a useful metaphor, and it's still used. > So does the Java interpreter. Java is famous (or infamous) for presenting an alternate shell to the programmer. With a little effort, it was possible to provide a full command-line shell written in pure Java. The beanshell is probably the most famous of those. It sports syntax derived from Java, and it's pretty complete as a command-line shell. > In > fact, so does any non-trivial application which has security features. Yeah, and you don't even need to mention security features, even though security "features" exist implicitly. > But > it doesn't mean the application has any back door past the OS's security. Sort of. The stopping problem has been way-over-used as an excuse to be lazy about security. But you can't have perfect security in any real system, and every application must be expected to open holes. And since talking about shells is talking about applications from a specific point of view, you have to expect shells to open holes. Likewise servers. >> 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. This does not mean, that does not mean. But every real system is insecure somewhere. Some are more so than others, but none is perfect. It's a fundamental problem with all systems. And every system is a shell/wrapper around the resources it is designed to manage. I'm not inventing new usage to the jargon here, even though the popular usage has moved underneath. >> 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. Why defend either excessively? I'm not suggesting we belly-up to Microsoft or Apple here, nor advocating a mass exodus to openBSD, etc. The best defense is understanding the weaknesses of your tools and using them the best you can, and preparing for the unfortunate possibilities. >> 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. When a user/programmer/system engineer/etc. fails to allocate purpose-specific users for each kind of network access you expect, the resulting configuration circumvents the privilege separation features of the OS. Sure that's a configuration issue more than an OS issue, but it's a limitation of all OSses. The people who build the OS don't necessarily know much about what we at this end plan to do with it. It's each user's responsibility to understand the security features at each layer and use them the best he can. But if you have to have proof that I've read a few of those, we can talk about integer overflows and sign overflows, we can talk about buffer overflows, we can talk about using both of those and other tricks to overwrite a return address through an unprotected pointer, or to write into a jump table, ... Why are you still insisting on attacking the messenger? Do you think there's a war going on here? If so, which side do you think I'm on? >>>>>> 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. And you say I dodge your questions. Which question did you intend to answer by telling me to learn security? Is it just because I happen to be trying to convince some people to use good security techniques using a different approach than you? >>> 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. Would you consider that I'm trying to describe bad habits that many of us are subject to, rather than assuming that I'm advising everyone to give in to those habits? > 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. Well, I'm sorry if it was a waste of your time. I suppose I should have thought out all the ways I could be misunderstood and presented a doctoral thesis in the original post, instead of just posting something that I hoped would prompt discussion. > Jerry -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/CAAr43iOvkdXCBxN2Bav0RMaicpJe4J=cqutbhvfdhorbw4g...@mail.gmail.com
