On Thu, 26 Sep 2019 07:38:01 -0700 Anselm Garbe <garb...@gmail.com> wrote:
Dear Anselm, > When I imagine quark as a drop-in / on demand temporary http server, I > would just imagine it'll assume the privileges/capabilities of the > user/group that is running it. > If I want it to have very rigid/limited permission, I'd execute it > with that user context rather hoping for it dropping privileges. Often > assuming a user requires root privileges, here the rotten concept > already starts. I want a permission and execution model, that is > imposed from the start. Dropping privileges is possible from the > surroundings that start it -- assumed creating a socket etc. is a > valid capability for the assumed user. that's how the ball rolls unfortunately. I would never consider using a server which does not chroot() or jail itself in some other way, let alone developing it. And unfortunately, many of those jails require high permissions. But I get your point. > > > Drop in by my definition means one does not run quark > > > permanently, it is just for temporary stuff. Like during > > > development you serve some generated documentation through it, or > > > when you want to share some files for the time being on a LAN. I > > > would always warn about quark not to be used in any production > > > setup, as it has never been properly reviewed or pen tested. > > > > I support your point with regard to OpenBSD. On Linux, it is a > > different matter, as there is no real suckless server that I know of > > which also provides the security we are used to from OpenBSD's > > httpd. > > Did you check http://www.nazgul.ch/dev_nostromo.html ? Well, it's using setuid, which is pretty horrific for a server. If your server is setuid and anyone can use it, you can easily use it to grab data from other users on a multiuser system. As I said earlier, the only "sane" solution is to use doas(1) and sudo(1). > The issue is you have to resist the feature load if quark is serious > about becoming THE drop-in option. Only tools that serve a single > purpose and maintain it rigidly are successful in the long run. I agree with that point and will think about dropping features. > Don't get me wrong, but I have been there and I have become way more > sceptical than this, with such claims. Often security flaws requiring > imagining the un-imaginable. In case of lazy clients or DDoS quark > might not become insecure itself, but screw other stuff on a server > etc. A truly safe and secure setup may require special rate limiting > on the firewall as well or specific request pattern processing in > terms of rigid timeouts etc. Unfortunately a (too?) simple > implementation can't address some of these cases, so for the sake of > simplicity it's good to declare the limits, which is why I'm > advocating the drop-in use case here. Nobody will expect a tank with > backup artillery when he orders a taxi. ;) Haha that's a great analogy! Well, a DoS could happen, I was more thinking about data leaks or something > Easy, just run two quarks, one on 8080 the other on 8090 and then tell > your clients domain1.org:8080 and domain2.org:8090 The "default" port is still 80. :P > Why would you give a fuck about those? If it's a drop in it's not > supposed to canonicalize to permanent redirects and temporary > redirects aren't needed either. Just because something is a drop-in doesn't mean it should be sloppy to save 50 lines of code. > > I see what you mean. Sadly nginx has become a bloated mess. > > It has become more bloated, but it's still pretty lean in comparison > to the abominations called apache or IIS ;) That's true! With best regards Laslo
