Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Russ Allbery contributed:
> > Well I meant that they would be used by systemd and ignored likely
> > noisily by default by others. However this really should be the job of
> > the service in any case as depending on a third party service for
> > security that isn't extra such as potentially PrivateTmp that apache/php
> > may need (likely in a /var chroot in this case though) is asking for
> > trouble.
>
> No, it should *not* be the job of each service to reimplement tricky
> security measures. They should be implemented in one place or a small
> number of competing places that are thoroughly tested and that have been
> examined with lots of eyeballs, and then reused by everyone else rather
> than having them attempt to roll their own strategies.
>
> This applies to several features in upstart and systemd. Socket
> activation is another excellent example. Anyone care to guess how much
> badly-written code to handle listening to a network socket currently
> exists in the archive? How much of it causes the daemon to fork and exit
> in the parent before it's actually listening to the network, thus breaking
> boot ordering? And that's despite the existence of the inet superserver,
> which hopefully a lot of packages are using rather than rolling their own.
>
> It's one thing to avoid a monoculture. It's quite another to chase
> avoidance of a monoculture into a nasty case of Not Invented Here.
> Services should not be responsible for doing things that can be done
> properly by well-tested and robust system services for exactly the same
> reason that services should not use their own implementation of AES and
> should instead rely on one of the several robust and well-tested crypto
> libraries.
Well I completely disagree, yes they should use or atleast reference
good well audited shared references but code for security should be
tailored to the almost always simpler job at hand otherwise you will
always be less secure and doing so actually increases eyeballs on the
code. Bringing it back to PrivateTmp what you are certainly doing is
adding complexity about whether systemd is running and has done this or
not and for what good reason, which then raises questions and less
audited code for all the other use cases. If you analyse the really
secure packages on the two sides guess which has the extremely low
vulnerability track record. You may also stop the dev from providing
extra layers of security because the generalised behaviour is out of
their domain and they don't need to think about it.
If on the other hand you are talking about making it easier for some
programmers who are not willing to take the time to be careful then you
may have a point for backing things like polkit but I would say they
should stick to unpriviledged user operations then as this
generalisation and misunderstanding/unfamiliarity does and will lead to
more exploits and they shouldn't be doing anything risky as root if
they are not willing to be careful anyway.
And no it isn't exactly the same reason as well defined libraries with
very specific low level jobs at all, often even standard c libraries
functions are the right tool but sometimes you take part of it and make
something more correct.
--
_______________________________________________________________________
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'
(Doug McIlroy)
In Other Words - Don't design like polkit or systemd
_______________________________________________________________________
Reply to: