On Sat, 22 Mar 2003 at 01:49:52 -0600, Joshua Brindle wrote:
> While we are pretty much set to use selinux for our MAC implementation we
> still need a lighter weight, less intrusive ACL implementation.
>
> natey has worked on systrace some, and we have a couple guys interested
> in grsecurity.
>
> The problem is that we have limited resources and should really focus on having
> 1 really good ACL implementation (by this i mean concentrating on writing policies,
> maintaining, documenting and recommending a particular implementation.) this does
> _not_ prohibit any number of acl systems being available in portage, but resources
> mandate that we persue only one as a full blown subproject. The question is
> which one. i was somewhat excited about systrace due to it's usability before i found
> out that it is not possible to apply system wide acl's with it. grsecurity can do this
> but isn't nearly as easy. are there others? does anyone have experience with
> any particular implementation, and have opinions on how easy to use, effective
> and stable please share that information.
Although I have been working on implementing systrace on Gentoo, and may
be a little biased, I do agree that one ACL subproject would better suit
the overall needs of the hardened-gentoo project.
For those who are unfamiliar with systrace, please see:
http://www.citi.umich.edu/u/provos/systrace/
Stability:
Systrace is currently integrated into both NetBSD and OpenBSD...which
implies that the *BSD version of the systrace code is stable enough to
meet the demands of those in the *BSD camp. While the Linux code
is still in development, it is seemingly quite stable when kernel
patches are applied to a vanilla 2.4.20 kernel. With the few problems
that we have found thus far, the systrace authors have been receptive
and fairly responsive. I believe that the systrace Linux code stability
will improve dramatically the more we test it and break it.
Usability:
Systrace is fairly easy to use...maybe not for the average user at
first, but with the gtk interactive policy frontend defining new
policies on the fly, it is relatively easy.
The concern that systrace is not enforcable system wide is one
that can be conquered in my opinion. Currently any systrace'd program
must be started as "systrace -a /path/to/binary" ...the workaround is
to create wrapper scripts/programs for systrace on a system scale, ie. a
wrapper for eliminating the need for suid/sgid binaries through
systrace priv elevation.
Addional arguments could be built into rc-update to start a systrace'd
daemon or listener, ie. "rc-update add sshd default -S"
Seamless and transparent integration of systrace *is* possible...but it
will require development time and energy to make it work as an
integrated part of the system.
Effectiveness:
Some of the possibilities with systrace are:
Application sandboxing/Virtual chroot'ing
Lightweight HIDS...policy violations are logged
Defined policies are enforced without user interaction...any system
calls not covered by a policy are denied and logged.
Privilege Elevation...enables nifty things like getting rid of suid/guid
binary reliance
Systrace is still fairly new...but the ease of use and effectiveness of
the the program (IMHO) are worth pursuing. The problems of system wide
deployment is a developer specific issue (on Gentoo)...and advances we
make here can likely be offerend up to the systrace authors for possible
inclusion and enhancement.
My $0.02,
~Nate
>
> note: please, please, for the sake of all the people on this list don't reply
> if you don't have experience with acl implementations or just want to
> hear yourself talk, it doesn't help anything. Thanks everyone
>
> Cheers
>
> Joshua Brindle
--
gentoo-hardened@g.o mailing list
|
