On Thu, 7 Feb 2002, Stephen Smalley wrote: > > On Thu, 7 Feb 2002 Valdis.Kletnieksat_private wrote: > > > I'm assuming that the goal here is to scan the environment being > > passed, and do something if you find something odd (for instance, > > LD_PRELOAD being set for a set[ug]id binary)? > > Right. Or more generally, LD_* being set for any program that causes an > increase in privilege/permissions when it is executed. ld.so only knows > about setuid/setgid, so it isn't aware of other security models (full > POSIX.1e capabilities, LIDS, TE, etc) where this might be a concern. > Right, but under the post-LSM paradigm, the application (ld) should fail due to restrictions, regardless of the environment. Environment variables are userspace constructs, are they not? It's possible that a program may make decisions based on these and STILL not be able to access the necessary objects. I'm confused (obviously): are we protecting objects or protecting application/root space programs. If we add the environment to our protections, shouldn't we have a common means of doing so? > -- > Stephen D. Smalley, NAI Labs > ssmalleyat_private > J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 : Thu Feb 07 2002 - 12:25:38 PST