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. > If so, are there any environment variables that a security module should > be scanning for, rather than the application handling it itself? Yes, > I know there *was* an LD_PRELOAD issue - but that got fixed where it should > be fixed. And in the general case, pre-filtering for sanity is probably > a lost cause - I've seen programs borked because one of the LC_* locale > environments was motified. On the other hand, I've personally used > (admittedly ugly) code like 'TZ=EST29EDT date +%m%d' to get yesterday's > date.... You can't expect ld.so to be aware of the security model of an arbitrary LSM security module, unless each project provides a modified ld.so. So filtering the LD_* variables may be reasonable for a security module. To some extent, the threat posed by the LD_* variables can be countered in other ways, e.g. controlling attempts to mmap with execute access and preventing more privileged domains from executing untrustworthy code. SELinux does this, and you consequently can't just point LD_PRELOAD to your own shared object when executing a program that causes a domain transition. But there is still the potential for mischief. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 - 08:13:21 PST