On Wed, 25 Sep 2019 at 23:27, Laslo Hunhold <dev_AT_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
Received on Thu Sep 26 2019 - 16:38:01 CEST