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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d1d0e7d.5030...@kvr.at