The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The unanswered Question

Christoph Lameter <clameter@waterf.org> writes:

> Why is the above setup a security risk?

The burden of proof doesn't rest on people to prove a program suid
root unsafe, it rests on anyone who wants to make a program suid.  At
least two critera must be met:

1) There has to be a completely compelling argument about why (on the
vast majority of systems) this binary has to be suid root to perform
its job, and why it's not sufficient to require the user to become
root before running it.

2) There has to be evidence that great care has been taken when
writing the software to consider all the implications of being run
suid, and handle them appropriately.  (I'm not a security expert, so I
don't even know what all those implications are.)

Only if both those conditions are met, should something be considered
as a candidate to be run suid root.

> Why do you assume that the binaries can be executed or their
> security holes be exploited by anyone on the system?

Because that is the appropriate default assumption.

> I have now to manually run some scripts after each upgrade on a
> server. We have 5 Linux servers, with more to come. Then there are some
> Linux workstations. It gets a little bit unnerving to always keep an eye
> on those things. The admin group can easily be handled by NIS.

Why not do this:

Have in /usr/local/bin/our-dpkg:

#!/bin/bash
dpkg $*
/usr/local/bin/our-configs

and in /usr/local/bin/our-configs

#!/bin/bash
chmod u+s /usr/sbin/statnet
chmod u+s /usr/sbin/strobe
etc...

Then just don't ever call dpkg.  Always call our-dpkg, and you're
guaranteed that your site specific suid settings stick.  I know this
is fairly primitive, but I'm sure you or someone else can come up with
an even better approach.

--
Rob

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com