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 |