On Wed, 25 Sep 2019 at 23:27, Laslo Hunhold <d...@frign.de> wrote: > quark drops all its permissions as soon as it has done all the things > it needs to do. This also includes that you can't accidentally serve a > root directory. To underline it further, quark _disallows_ itself to > run as root while serving for this precise reason (and the reasons > discussed earlier not to escape the chroot).
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 what users are for. doas and sudo are just hacks/workarounds. > > quark doesn't explicitly require root. If you solve this problem with > capabilities or whatnot you don't need root and quark won't complain. I clarified what I mean above. > > 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 ? Once suckless.org was using this, long time ago. 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. > With regard to security: I see no way quark could be exploited after > the permission drop. It only has read-only access (by unveil()) to the > serve directory that we can assume not to contain secret information > anyway. Even if there was some exploit within the serve()-step, you > can't really do much damage. 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. ;) > > With this definition there is really no justification at all to > > support vhosts. If you need to serve different directory roots (that > > typically may translate to different vhosts in classic setups), just > > run different quark instances on different ports, that's the point I'm > > making here. > > So how would that work if I wanted to serve both the domains > "domain1.org" and "domain2.org" with quark? Both requests go to port 80. Easy, just run two quarks, one on 8080 the other on 8090 and then tell your clients domain1.org:8080 and domain2.org:8090 > > If you remove vhost handling you will be able to remove all kinds of > > cruft, like redirect handling etc. > > That's not true. We need to have redirect handling to "discard" non > canonical requests, and other things. 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. > > If I want to run a real httpd on Linux, I'd stick to nginx... but if I > > quickly want to serve some stuff until tonight in directory XY, I'd > > consider a quark as I described. > > 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 ;) Best regards, Anselm