Re: securing/monitoring Debian devel environment
On 12/22/2010 05:10 PM, Yaroslav Halchenko wrote:
> 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.
In private communication, Yaroslav and I have been bouncing some crude
ideas around, which I'm going to summarize here.
Of the possible approaches we discussed, two seem to fulfill the
requirements above:
* SystemTap [0,1]
* auditd [2,3]
[0] http://sourceware.org/systemtap/
[1] http://packages.debian.org/sid/systemtap
[2] http://people.redhat.com/sgrubb/audit/
[3] http://packages.debian.org/sid/auditd
note that SELinux was excluded for the reasons Yaroslav mentioned above.
SYSTEMTAP: The SystemTap approach appeared the most promising at first
glance, as it is fully scriptable and the Beginner's Guide contains
ready-to-use scripts covering basically all the requirements mentioned
above. Yaroslav also discussed this with #systemtap, they pointed out
some issues WRT fork()s etc but otherwise had no major objections.
SystemTap has one drawback: it requires a kernel with debugging stuff
enabled (see #568866), which AFAIUI is only available on i386/amd64 and
requires 1.5GB disk space.
AUDITD: Seeing that SystemTap's purpose goes way beyond simple auditing,
I took a shot at auditd -- which is supported by the standard kernel --
with the goal of producing a simple wrapper script for debuild.
My initial optimism and success was dampened as I gained more experience
with auditd and it's goals. To elaborate, it is quite simple to create
auditing rules achieving the goals above, however an approach "tailored"
to package-build-audit *only* is a pain. For example, it is easy to
monitor *all* access to /etc/shadow or changes to /bin/login, it is
quite hard to limit the monitoring to a *process tree* (our building
process).
Furthermore, generating sensible reports from the data above wasn't all
too easy as well. ausearch and aureport are very useful, but one must
still pre- or postprocess their respective outputs to get the desired
results.
Finally, it appears -- at least to me -- that Prelude IDS (already
packaged) is the way to go. It is a full-scale, real-time IDS (using the
auditing subsystem) with numerous features including plugin support for
sensors and also good reporting. The initial objective is just a subset
of Prelude's goal, and seeing as there is a lot of weight thrown behind
Prelude, the merit of a custom solution (based on the raw auditing data)
is probably debatable.
Anyway, I'm at my limits here -- even though the idea and the available
technology is highly interesting, I do not have the necessary time
available ATM to go deeper. If there's anyone security-minded with time
on his/her hands, the ball is yours...
Regards,
Christian
Reply to: