* $ from dawat_private at "21-Apr: 9:36pm" | sed "1,$s/^/* /" * * * >On 21 Apr 2001, David Wagner wrote: * >> Crispin Cowan wrote: * >> >Applications that do want to learn this kind of thing normally use the * >> >access() system call, and that call should continue to function. * >> * >> It may be relevant to also mention that applications that want to * >> call access() or equivalent are also often broken, so any policy * >> module that supports such apps might also be referred to as "broken" * >> from another viewpoint. :-) * > * >I don't think security-aware-polite programs are "broken" if they want * >to use access() to "size up the situation", [...] * * Well, my remark should only be taken half-seriously, as stated. It * was intended as a lighthearted attempt to remind folks that whether * to support access() or not is a question of policy and thus, I would * argue, should be left up to the policy module. * * Second, may I suggest that you take a look at my prior message? * http://mail.wirex.com/pipermail/linux-security-module/2001-April/000092.html * I explain why it is not unreasonable for one's security policy to say * "use of access() is a bug": it often leads to TOCTTOU vulnerabilities. * * Once again, I propose the following: If you want to build a policy * module that adds extra semantics to access(), feel free -- but I would * like to be free to build a policy module that ignores access() [or even * kills any process that uses it, if I wish]. If that's what you want, do it, but ~20% of the programs I have data on use access() broken or not. Such classic apps as bash cp login mail rm rpm ifconfig init lilo chage chsh man passwd useradd (all in all 55 out of 272 programs call access) My problem with this whole userland requirements is that I didn't set it up to well, the whole "can I open this file?, okay open the file" is an over-simplification of what I really wanted to get over, and that is :- "some applications (sendmail,id) because of their very nature, will need to make policy decisions or display policy specific information. We should bear this in mind when designing the LSM so that we do not stop this happening (we don't need to do it in this project, we just need to make sure we don't stop someone else from doing it). The goal that I have in mind is that we should not force appliations to fork or to rely on ifdefs to support different policies, not only is this good for application writers, but its good for policy writers/security researchers as well. Removing the requirement to come up with a complete OS solutiuon (kernel+policy+userland) will also make it easier to invetigate new approaches to security." How do I get to my goal ? Ahh, that's the big one. I wrote the concept of PACM on my whiteboard on Friday hoping that the code faires would come in over the weekend and fix it, but no luck, perhaps I need to leave out some milk and cookies as well ? (probably tequila would work better around here).... richard. ----------------------------------------------------------------------- Richard Offer Technical Lead, Trust Technology. "Specialization is for insects" __________________________________________http://reality.sgi.com/offer/ _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Apr 23 2001 - 10:48:42 PDT