1 |
pageexec@××××××××.hu wrote: |
2 |
> On 26 Apr 2006 at 13:38, Joshua Brindle wrote: |
3 |
> |
4 |
>> That is silly. The model is to essentially sandbox apps. The problem is |
5 |
>> that the sandbox is leaky due to the abstractions being used (eg., |
6 |
>> paths). There is no way to determine that the policy you wrote is |
7 |
>> actually being enforced, and again, escalating privileges and increasing |
8 |
>> the potential for misuse. |
9 |
>> |
10 |
> |
11 |
> is there any particular reason you're avoiding answering my (Andrea's, |
12 |
> for that matter) requests for specific attack examples? |
13 |
> |
14 |
> it's my observation that you as well as many other selinux advocates |
15 |
> often try to stay at some superficial theoretical level of 'attacks' |
16 |
> as if that meant anything in the real world. it means nothing, so |
17 |
> please try get down from that 'high horse' and answer the questions. |
18 |
> |
19 |
I do not believe that specifying a specific vulnerability is required |
20 |
for a model to be broken. I also do not actively try to break systems |
21 |
(penetrate and patch methodology) to decide if they are broken, any |
22 |
theoretical problem with the model is exploitable in the worst case |
23 |
scenario, that is enough. There is nothing 'high horse' about it, do you |
24 |
think people that build skyscrapers have to see the natural disasters |
25 |
that will destroy the buildings first hand? No, they have models for |
26 |
everything, the sky scraper itself, the possible 'attacks', etc. |
27 |
> <snip> |
28 |
>> That is absolutely false. If some person sells selinux as The Solution |
29 |
>> that is one thing, I have never said and will never say that SELinux is |
30 |
>> any kind of end all for security. |
31 |
>> |
32 |
> |
33 |
> what is it that you say about selinux then? clearly, you must have an |
34 |
> opinion about its place in the world of security solutions. i.e., is |
35 |
> there (according to you) a situation where say apparmor or grsecurity |
36 |
> provide better security (you get to define what security means in that |
37 |
> situation) than selinux? i'm all ears ;-). you realize that if you |
38 |
> cannot provide such a situation then you'll have effectively confirmed |
39 |
> my statement. |
40 |
> |
41 |
> |
42 |
what best suits your needs depends on your security needs. I've always |
43 |
said this in hardened. I have no need to create imaginary situations, |
44 |
I've suggested to many people in #gentoo-hardened that grsecurity might |
45 |
meet their needs better than other solutions. |
46 |
> <snip> |
47 |
> |
48 |
> you suggested that systrace should be rejected (among others) because |
49 |
> it allows the user to (re)define the policy based on feedback from the |
50 |
> access control mechanism. all i pointed out was that the same applies |
51 |
> to selinux as well (and it does happen in real life too) yet you're |
52 |
> not suggesting its removal. you can't have it both ways. |
53 |
> |
54 |
> |
55 |
There is a huge difference between a policy loaded into the kernel that |
56 |
is mandatory at all times (and can be modified when necessary) and a |
57 |
policy that is in userspace, is entirely dynamic, and pops up with a |
58 |
dialog when a new access attempt happens. Clearly the policy has to |
59 |
change to the environment, however in general MAC policies should not be |
60 |
changing at run time. Since the systrace author has said that systrace |
61 |
is not and does not want to be MAC this might be a non-issue. Just as |
62 |
long as anyone using systrace knows they aren't using a mandatory access |
63 |
control system. |
64 |
>> umm, its pretty obvious, want a picture? here: |
65 |
>> |
66 |
>> SELinux: |
67 |
>> attacker --> kernel DAC/capability checks --> selinux access checks --> |
68 |
>> capabilities granted. |
69 |
>> systrace: |
70 |
>> attacker --> systrace --> capabilities granted. |
71 |
>> |
72 |
> |
73 |
> and? this is not an attack vector, this just describes how things |
74 |
> work at some conceptual level. an attack is where you demonstrate |
75 |
> how you exploit the above mechanism to gain privileges that weren't |
76 |
> otherwise granted to you by the systrace policy. note that i'm not |
77 |
> saying that such an attack doesn't exist, it's just that you have |
78 |
> yet to demonstrate one. |
79 |
> |
80 |
> |
81 |
Eh? that _is_ an attack vector. you are asking for a PoC exploit which |
82 |
is not something I'm interested in that sort of thing at all. Again, you |
83 |
do not need a reproducible exploit to have a broken model. |
84 |
>>> <snip> |
85 |
>>> |
86 |
>> Sorry, apparmor isn't even in the same class as grsec in terms of the |
87 |
>> security it provides, I probably shouldn't have coupled them like that :) |
88 |
>> |
89 |
> |
90 |
> oh the tears of joy... can't believe you actually said that. |
91 |
> more seriously, more on the blog. |
92 |
> |
93 |
> |
94 |
I'm not sure why you can't believe I said that. grsec has several |
95 |
advantages over apparmor, the primary one probably being that it can |
96 |
actually do access control on the entire system rather that an |
97 |
app-by-app basis (which apparmor explicitly limit themselves to).. |
98 |
apparmor decided to build simplicity into their model instead of making |
99 |
their model extensive and simplifying the policy writing/generation. |
100 |
grsecurity has similar deficiencies, such as IPC. The reason is that |
101 |
grsecurity specifically targets system/app integrity and not information |
102 |
flow. The claim from the grsec author will be that IPC isn't a real |
103 |
attack vector, and in practice it might not be for more systems but |
104 |
there are many systems that are very sensitive to information flow and |
105 |
need IPC protection. grsecurity wouldn't be sufficient for those |
106 |
systems, it may be for others. |
107 |
>> umm, "rebuked".. if you want to call it that, claiming that "hacking is |
108 |
>> cool" is hardly compelling. The ideas on that page are good pointers in |
109 |
>> general for security systems, I never saw anything claiming the actual |
110 |
>> points were inaccurate *shrug* |
111 |
>> |
112 |
> |
113 |
> start here: http://marc.theaimsgroup.com/?l=dailydave&m=112638071303189&w=2 |
114 |
> |
115 |
> and please tell me you're not running with a+x. |
116 |
> |
117 |
> |
118 |
The answer to that email is simple. You don't need an access control |
119 |
matrix of a million elements if you have equivalence classes (something |
120 |
widely used in SELinux), see |
121 |
http://securityblog.org/brindle/2006/03/23/the-myth-of-least-privilege-or-why-we-love-equivalence-classes/ |
122 |
the a+x in $PATH argument is a strawman, anything you run is under your |
123 |
privilege level (whether that's the DAC uid or the MAC domain (or |
124 |
however it is implemented)) |
125 |
> <snip> |
126 |
> actually, the folks who wrote CC are very clever in my opinion, they |
127 |
> have clearly understood what information security is all about and it's |
128 |
> not their fault that many 'experts' of our time sell their concepts to |
129 |
> completely wrong markets. |
130 |
> |
131 |
> |
132 |
Glad to hear it... |
133 |
>> Personally I'd like to help security in general. Fedora has SELinux |
134 |
>> enabled by default and protects several daemons by default. This is |
135 |
>> clearly a win for security, MAC in a general use OS is unheard of, we |
136 |
>> are breaking new ground here. |
137 |
>> |
138 |
> |
139 |
> i was saving this for the blog, but since you've brought it up... |
140 |
> |
141 |
> you've just proved how dangerous spreading false sense of security |
142 |
> is. the targeted policy you're talking about does not give any real |
143 |
> security and coming from a self-described expert on selinux, it's |
144 |
> really disheartening to see as you should know better than that. |
145 |
> |
146 |
> |
147 |
Once again, you are confusing policy and mechanism. Just because the |
148 |
targeted policy doesn't restrict everything on the system doesn't say |
149 |
anything at all about the mechanism. Second, the targeted policy never |
150 |
claims to protect everyone from everything, quite the opposite, the name |
151 |
"targeted" pretty clearly states that certain things are restricted. |
152 |
Now, the difference between the selinux targeted and other systems is |
153 |
that with the targeted you can actually analyze the policy and ensure |
154 |
that the targeted domains can't affect the integrity of the rest of the |
155 |
system, which is impossible with path based systems. |
156 |
|
157 |
Also, where have I ever said that I'm an expert on security or selinux? |
158 |
I do not appreciate blatant attempts to misinform or discredit people, |
159 |
don't do that. |
160 |
> it is a bandage for the utter usability mess that selinux is and |
161 |
> 'everyone' had complained about. practical example, what does |
162 |
> restricting nscd by a policy help (and i'm generously ignoring the |
163 |
> possibility of exploiting a kernel bug in a two stage attack) when |
164 |
> an exploit can just go for an unconfined application (plenty of them |
165 |
> left)? so yeah, a clear win and breaking new ground there... no. |
166 |
> |
167 |
On recent targeted systems most, if not all, network daemons are |
168 |
confined. Its pretty obvious that an "unconfined" application is... wait |
169 |
for it... not confined! wow, I'm very glad that you can use a |
170 |
dictionary. I don't think anyone expects unconfined applications to be |
171 |
... well.. confined. If they do they've been grossly misinformed, I take |
172 |
no credit for anything here.. |
173 |
>> Incase you forgot hardened *does* support grsec, RSBAC and SELinux. |
174 |
>> grsec is in no way a second class citizen, when people come to the |
175 |
>> channel with problems I try to help them, I don't tell them they are |
176 |
>> stupid and need to switch to SELinux. |
177 |
>> |
178 |
> |
179 |
> i think you misunderstood me. i don't care what opinion you hold about |
180 |
> grsec or apparmor or whatever as much as i care about not spreading |
181 |
> false sense of security. you drew a clear and obvious line between |
182 |
> selinux and the rest of the world ("grsec/apparmor implement one of the |
183 |
> dumbest ideas in security", that's what you stated effectively), and |
184 |
> that's simply not right so you will have to defend your opinion or eat |
185 |
> those words, your choice. |
186 |
> |
187 |
> |
188 |
I think you misunderstanding. I claim that path based access control is |
189 |
flawed for all the reasons I've listed (which you haven't refuted) at an |
190 |
ideal and philosophical level. There are a number of practical and |
191 |
technical issues with this as well (see the LSM list over the last week |
192 |
or so...) But I haven't talked about those at all, I'm not sure where |
193 |
you are coming from here. |
194 |
>> I even suggest that people who have very lightweight security needs |
195 |
>> use grsecurity. In practice (eg., normal systems, normal people, etc) |
196 |
>> grsec can be very effsective. |
197 |
>> |
198 |
> |
199 |
> although i wasn't talking about grsec per se, but now you made me curious. |
200 |
> what the heck is 'lightweight security'? and how come that a system |
201 |
> implementing one of the dumbest ideas in security can be effective? |
202 |
> effective at what? being dumb? or perhaps, providing 'security'? what |
203 |
> would that 'security' mean then and why cannot selinux provide it? |
204 |
> |
205 |
> |
206 |
Once again, security is about your requirements and possible tradeoffs. |
207 |
>> I'm not sure what "you asked for it, we'll see how smart you(r) selinux |
208 |
>> folks are" is suppose to mean, is that a threat? Are you going to make |
209 |
>> fun of us on blogs and mailing lists? |
210 |
>> |
211 |
> |
212 |
> you already pulled that feat off, so i'm left with the task of putting |
213 |
> the pieces of the puzzle together for all to see. |
214 |
> |
215 |
Ok, have fun with that. I'm going to be gone after today until next week |
216 |
so don't misconstrue my lack of reply as assent. |
217 |
-- |
218 |
gentoo-security@g.o mailing list |