securing/monitoring Debian devel environment

December 22nd, 2010 - 11:20 am ET by Yaroslav Halchenko | Report spam

Dear Debian Comrades,

I can take blame if I am the only one who is somewhat jeopardizing our
project by relying solely on his own eyes, fingers, GIT, belief in a
good will of upstream developers, and moreover trust in the security of
the upstream developers systems and their repositories.

But I guess, I am more of a typical Debian contributor, who develops
Debian contributions on the same system where sensitive keys (SSH, GPG)
are kept and even more -- ssh/gpg-agents are running from time to time.
I do inspect upstream code, and I do check on good intentions of
upstream developers; but I am not relying on some automated (thus
objective) way to assure that my system does not get jeopardized while
the package is being built (in my account or may be as root under
pbuilder) or tested.

If upstream code, for some reason, contained malicious code which
would set up a backdoor or simply perform some malicious actions
targeting Debian servers/uploads, it would be unfortunately possible for
it to take advantage of my system having access to debian infrastructure
(may be not right away, since keys would not be loaded atm and I do use
passphrases; but at a later point after injection of the malicious
script). The only way to completely prevent that would be to develop and
build packages in a completely isolated (virtual machine) environment
with good monitoring/reporting facilities if some abnormal actions
(unwarranted access to the network, creation/editing/adding files
outside of the build-tree) have happened.

So, I wondered what available software solutions other Debian
contributors might be already using to assure the security of their
systems while working on the upstream code
(building/packaging/running). (just to make clear, sanitising the
environment by debuild is not enough)

May be there is a lightweight utility which could be used for
monitoring, e.g. it would report suspicious actions being taken from
within a monitored environment? e.g., it would

* sanitize environment variables
* monitor open/socket/... syscalls and report abnormal activities
(e.g. opening network connection, writing to a file outside of
build-tree,/tmp/, etc)
* provide a summary at the end on the invoked actions by the target
command

I guess a possible solution which would not only monitor but
guarantee would be SELinux, but I am afraid it might be somewhat
cumbersome to setup policies across the variety of packages I maintain.
So I just wanted to monitor to start with.

Any recommendations on existing solutions/setups would be really welcome
;)

Yours truly,
==
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic





To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20101222161013.GD8747@onerussian.com
email Follow the discussionReplies 4 repliesReplies Make a reply

Replies

#1 Yaroslav Halchenko
December 22nd, 2010 - 05:20 pm ET | Report spam
On Wed, 22 Dec 2010, Timo Juhani Lindfors wrote:
> script). The only way to completely prevent that would be to develop and
> build packages in a completely isolated (virtual machine) environment
Interesting ideas but don't you also need to run the produced binaries
in isolation?



exactly -- that is what I meant by 'built (...) and *tested*' ;)

If we assume a malicious upstream they can surely make
the build innocent but then have the produced binaries launch sudojump
>...<



sure -- many bad things can happen in various reincarnations of the
malicious desires of upstreams or just those who hijack their
projects/distribution ;-)

the question remains: how could we set our development
environments so they remain convenient to use and would help us to
detect such misdemeanours so we keep Debian infrastructure secure.

Pure isolation of build/test environment would help, but without easy
monitoring, it would just postpone detection of malicious attempts so
they would activate (again) during builds across our buildd farm, or
running on the boxes of those who installed the packages (often DDs as
well, since we do eat our own ...)

=Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

Similar topics