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:

> I have the following files on all my servers (except the Shell Server):
>
> [miriam]~:l /usr/sbin/{strobe,statnet}
> -rwsr-x---   1 root     admin       50404 Sep 11 12:14 /usr/sbin/statnet
> -rwsr-x---   1 root     admin       10636 Sep 11 12:14 /usr/sbin/strobe
>
> [...]
> Why is the above setup a security risk?

It isn't if you want to allow the `admin' group to get root access.
However, if someone can manage to gain `admin' group access, perhaps
via a setgid binary, then it is a security risk.

*If* in a Debian package, it would be a violation of the Debian policy
manual.  To be compliant, they would have to be mode 4754.

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

Complex question.  See my other post on the subject of loaded
questions.

Safe answer: I don't assume that, but neither do I assume that they
can't be exploited just because it isn't obvious how that could
happen.  I mean, most sendmail bugs aren't obvious to me.  :-)

To achieve a secure system, you can't assume everything is going to
work the way it should or the way you expect it.  Most security holes
are the result of many small bugs that, when put together by a
cracker, allow things to happen that you never expected or desired.

There is also some danger that some stupid person will change the
final mode octet to 5.  It would be a good idea in this case to make
the binary mode 4754 *and* program it AS IF it would be installed
4755.  That way, two failures are required for the program to be
exploited and not just one.

> I would like to package netdiag in some way that it generates the
> permissions indicated above on install/upgrade.
>
> 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.

NIS is very insecure and can be spoofed.  Relying on it may be a bad
idea.  For example, if someone can pretend to be an NIS server, then
they can include themselves in the admin group.

-- 
Daniel Quinlan <quinlan@pathname.com>  |  finger quinlan@pathname.com for PGP
quinlan@transmeta.com (at work)        |  http://www.pathname.com/~quinlan/

--
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