Re: daemontools-encore version 1.03 released

--0016362842de049f640494c72b33
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

This reminds me of a patched version of setuidgid that I proposed back in
2004
to "inherit" all the auxilliary groups of a given user:

    http://www.wolfendens.com/code/as_user.c

l can see advantages to both this approach and one where the GIDs are
specified
explicitly - although from a security perspective the latter may be
preferable, I find
the former simpler to manage - of course I'm biased!

I was feeling proud of myself for using a similar system to enforce "least
privilege"
when I happened upon a 2007 paper by Dan Bernstein called "Some thoughts on
security after ten years of qmail 1.0", in which he wrote:

    I have become convinced that this =93principle of least privilege=94 is
fundamentally
    wrong. Minimizing privilege might reduce the damage done by some
security
    holes but almost never fixes the holes. Minimizing privilege is not the
same as
    minimizing the amount of trusted code, does not have the same benefits
as
    minimizing the amount of trusted code, and does not move us any closer
to a
    secure computer system.

Ouch.

Of course, we all know there *are* benefits to minimizing privilege, and
that's one
of the reasons some of us are moved to use (and patch) daemontools. But I
take
Dan's point to be that we must never forget that there's only so much you
can do
at the sysadmin level to contain the risks posed by vulnerable code.

Cheers,

    Peter

On Tue, Nov 9, 2010 at 2:21 PM, Bruce Guenter <[email protected]> wrote:

> Hi.
>
> I've just put daemontools-encore version 1.03 up at
>
>        http://untroubled.org/daemontools-encore/
>
> This release adds a -s option to setuidgid to set the supplemental GIDs
> (thanks to SATOH Fumiyasu), and fixes a couple of warnings and potential
> compile errors.
>
> (sorry for the duplicate message, the subject was wrong on the first)
>
> -----
>
> daemontools-encore is a collection of tools for managing UNIX services.
> It is derived from the public-domain release of daemontools
> (http://cr.yp.to/daemontools.html) by D. J. Bernstein.
>
> daemontools-encore adds numerous enhancements above what daemontools
> could do while maintaining backwards compatibility with daemontools.
> See the CHANGES file for more details on what features have been added.
>
> --
> Bruce Guenter <[email protected]>                http://untroubled.org=
/
>

--0016362842de049f640494c72b33
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

This reminds me of a patched version of setuidgid that I proposed back in 2=
004<br>to &quot;inherit&quot; all the auxilliary groups of a given user:<br=
><br>=A0=A0=A0 <a href=3D"http://www.wolfendens.com/code/as_user.c">http://=
www.wolfendens.com/code/as_user.c</a><br>
<br>l can see advantages to both this approach and one where the GIDs are s=
pecified<br>explicitly - although from a security perspective the latter ma=
y be preferable, I find<br>the former simpler to manage - of course I&#39;m=
 biased!<br>
<br>I was feeling proud of myself for using a similar system to enforce &qu=
ot;least privilege&quot;<br>when I happened upon a 2007 paper by Dan Bernst=
ein called &quot;Some thoughts on<br>security after ten years of qmail 1.0&=
quot;, in which he wrote:<br>
<br>=A0=A0=A0 I have become convinced that this =93principle of least privi=
lege=94 is fundamentally<br>=A0=A0=A0 wrong. Minimizing privilege might red=
uce the damage done by some security<br>=A0=A0=A0 holes but almost never fi=
xes the holes. Minimizing privilege is not the same as<br>
=A0=A0=A0 minimizing the amount of trusted code, does not have the same ben=
efits as<br>=A0=A0=A0 minimizing the amount of trusted code, and does not m=
ove us any closer to a<br>=A0=A0=A0 secure computer system.<br><br>Ouch.<br=
><br>Of course, we all know there *are* benefits to minimizing privilege, a=
nd that&#39;s one<br>
of the reasons some of us are moved to use (and patch) daemontools. But I t=
ake<br>Dan&#39;s point to be that we must never forget that there&#39;s onl=
y so much you can do<br>at the sysadmin level to contain the risks posed by=
 vulnerable code.<br>
<br>Cheers,<br><br>=A0=A0=A0 Peter<br><br><div class=3D"gmail_quote">On Tue=
, Nov 9, 2010 at 2:21 PM, Bruce Guenter <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:[email protected]">[email protected]</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-=
left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi.<br>
<br>
I&#39;ve just put daemontools-encore version 1.03 up at<br>
<br>
 =A0 =A0 =A0 =A0<a href=3D"http://untroubled.org/daemontools-encore/" targe=
t=3D"_blank">http://untroubled.org/daemontools-encore/</a><br>
<br>
This release adds a -s option to setuidgid to set the supplemental GIDs<br>
(thanks to SATOH Fumiyasu), and fixes a couple of warnings and potential<br=
>
compile errors.<br>
<br>
(sorry for the duplicate message, the subject was wrong on the first)<br>
<br>
-----<br>
<br>
daemontools-encore is a collection of tools for managing UNIX services.<br>
It is derived from the public-domain release of daemontools<br>
(<a href=3D"http://cr.yp.to/daemontools.html" target=3D"_blank">http://cr.y=
p.to/daemontools.html</a>) by D. J. Bernstein.<br>
<br>
daemontools-encore adds numerous enhancements above what daemontools<br>
could do while maintaining backwards compatibility with daemontools.<br>
See the CHANGES file for more details on what features have been added.<br>
<font color=3D"#888888"><br>
--<br>
Bruce Guenter &lt;<a href=3D"mailto:[email protected]">bruce@untroubled.=
org</a>&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<a href=3D"http://untroubled.org=
/" target=3D"_blank">http://untroubled.org/</a><br>
</font></blockquote></div><br>

--0016362842de049f640494c72b33--