Gentoo Archives: gentoo-hardened

From: Nate Underwood <gentoo@×××××.com>
To: Joshua Brindle <method@g.o>
Cc: gentoo-hardened@g.o
Subject: Re: [gentoo-hardened] ACL implementations
Date: Sat, 22 Mar 2003 08:30:35
Message-Id: 20030322083025.GA94212@natey.com
In Reply to: [gentoo-hardened] ACL implementations by Joshua Brindle
1 On Sat, 22 Mar 2003 at 01:49:52 -0600, Joshua Brindle wrote:
2 > While we are pretty much set to use selinux for our MAC implementation we
3 > still need a lighter weight, less intrusive ACL implementation.
4 >
5 > natey has worked on systrace some, and we have a couple guys interested
6 > in grsecurity.
7 >
8 > The problem is that we have limited resources and should really focus on having
9 > 1 really good ACL implementation (by this i mean concentrating on writing policies,
10 > maintaining, documenting and recommending a particular implementation.) this does
11 > _not_ prohibit any number of acl systems being available in portage, but resources
12 > mandate that we persue only one as a full blown subproject. The question is
13 > which one. i was somewhat excited about systrace due to it's usability before i found
14 > out that it is not possible to apply system wide acl's with it. grsecurity can do this
15 > but isn't nearly as easy. are there others? does anyone have experience with
16 > any particular implementation, and have opinions on how easy to use, effective
17 > and stable please share that information.
18
19 Although I have been working on implementing systrace on Gentoo, and may
20 be a little biased, I do agree that one ACL subproject would better suit
21 the overall needs of the hardened-gentoo project.
22
23 For those who are unfamiliar with systrace, please see:
24 http://www.citi.umich.edu/u/provos/systrace/
25
26 Stability:
27
28 Systrace is currently integrated into both NetBSD and OpenBSD...which
29 implies that the *BSD version of the systrace code is stable enough to
30 meet the demands of those in the *BSD camp. While the Linux code
31 is still in development, it is seemingly quite stable when kernel
32 patches are applied to a vanilla 2.4.20 kernel. With the few problems
33 that we have found thus far, the systrace authors have been receptive
34 and fairly responsive. I believe that the systrace Linux code stability
35 will improve dramatically the more we test it and break it.
36
37 Usability:
38
39 Systrace is fairly easy to use...maybe not for the average user at
40 first, but with the gtk interactive policy frontend defining new
41 policies on the fly, it is relatively easy.
42
43 The concern that systrace is not enforcable system wide is one
44 that can be conquered in my opinion. Currently any systrace'd program
45 must be started as "systrace -a /path/to/binary" ...the workaround is
46 to create wrapper scripts/programs for systrace on a system scale, ie. a
47 wrapper for eliminating the need for suid/sgid binaries through
48 systrace priv elevation.
49
50 Addional arguments could be built into rc-update to start a systrace'd
51 daemon or listener, ie. "rc-update add sshd default -S"
52
53 Seamless and transparent integration of systrace *is* possible...but it
54 will require development time and energy to make it work as an
55 integrated part of the system.
56
57 Effectiveness:
58
59 Some of the possibilities with systrace are:
60
61 Application sandboxing/Virtual chroot'ing
62 Lightweight HIDS...policy violations are logged
63 Defined policies are enforced without user interaction...any system
64 calls not covered by a policy are denied and logged.
65 Privilege Elevation...enables nifty things like getting rid of suid/guid
66 binary reliance
67
68 Systrace is still fairly new...but the ease of use and effectiveness of
69 the the program (IMHO) are worth pursuing. The problems of system wide
70 deployment is a developer specific issue (on Gentoo)...and advances we
71 make here can likely be offerend up to the systrace authors for possible
72 inclusion and enhancement.
73
74 My $0.02,
75
76 ~Nate
77
78 >
79 > note: please, please, for the sake of all the people on this list don't reply
80 > if you don't have experience with acl implementations or just want to
81 > hear yourself talk, it doesn't help anything. Thanks everyone
82 >
83 > Cheers
84 >
85 > Joshua Brindle
86
87 --
88 gentoo-hardened@g.o mailing list

Replies

Subject Author
Re: [gentoo-hardened] ACL implementations Justin Heesemann <jh@××××××.org>