* Stephen Smalley (sds@private) wrote: > On Tue, 2005-02-22 at 13:40 -0500, Colin Walters wrote: > > One thing I wonder is if there's any other issues tied to legacy > > binaries that would possibly make sense to control via this interface. > > checkreqprot is a fairly specific name; You had suggested legacycompat > > earlier? > > As is, the patch won't affect any execute-related checking that is > requested by the application, and that includes anything requested by > ld.so. Hence, for example, running gpg on a FC3 system still triggers > an execmod check against the gpg binary but no longer triggers various > other execute-related checks that were being caused by the read-implies- > exec logic in the kernel. That seems appropriate to me, and much more > manageable in the policy. We can't distinguish what ld.so does from > what the "application" does in the kernel, and I don't think we want to > try heuristics there. The only clean distinction is between what was > requested by the caller vs. what the kernel is applying. By heuristics did you mean taking current->personality into account and trying to guess what the caller asked for? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Tue Feb 22 2005 - 13:02:17 PST