Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]
Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename"): > [stuff] Thanks for your explanations and sorry for being dense. > In secure-execution mode, preload pathnames containing slashes are > ignored. Furthermore, shared objects are preloaded only from the > standard search directories and only if they have set-user-ID mode bit > enabled (which is not typical). Obviously it wouldn't be right for eatmydata to be loaded by actually setuid programs. Ian Jackson writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename"): > (As an aside, I'm not sure why it makes sense for apparmor to inhibit > preloading. I thought apparmor was intended to restrict the > applications you apply it to, not defend them against their callers.) So the overall effect is that programs with apparmor profiles are mostly protected from the effects of LD_PRELOAD (and, I assume, LD_LIBRARY_PATH and various other properties of the execution environment). This doesn't seem correct to me. Is there any documentation giving a rationale for this ? Is there a way to change this locally ? (Other than creating /etc/suid-debug, which is dangerous.) Ian.
Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]
On 2020-06-23 14:17, Ian Jackson wrote: > > Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks > with plain filename"): > > [stuff] > > Thanks for your explanations and sorry for being dense. > > > In secure-execution mode, preload pathnames containing slashes are > > ignored. Furthermore, shared objects are preloaded only from the > > standard search directories and only if they have set-user-ID mode bit > > enabled (which is not typical). > > Obviously it wouldn't be right for eatmydata to be loaded by actually > setuid programs. > > Ian Jackson writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks > with plain filename"): > > (As an aside, I'm not sure why it makes sense for apparmor to inhibit > > preloading. I thought apparmor was intended to restrict the > > applications you apply it to, not defend them against their callers.) > > So the overall effect is that programs with apparmor profiles are > mostly protected from the effects of LD_PRELOAD (and, I assume, > LD_LIBRARY_PATH and various other properties of the execution > environment). Yes, and also GCONV_PATH, GETCONF_DIR, HOSTALIASES, LOCALDOMAIN, LOCPATH, MALLOC_TRACE, NIS_PATH, NLSPATH, RESOLV_HOST_CONF, RES_OPTIONS, TMPDIR, and TZDIR. > This doesn't seem correct to me. Is there any documentation giving a > rationale for this ? Is there a way to change this locally ? I do not know enough about apparmor and its threat model to know if it should be considered or not. From the glibc point of view, nothing can be really done, it just obeys the AT_SECURE flag passed by the kernel. Now looking at apparmor.d(5), it seems it *might* be controlled by the change_profile option with the safe and unsafe mode. But I don't speak apparmor fluently enough to actually know how to introduce that option in a profile. > (Other than creating /etc/suid-debug, which is dangerous.) Yes, this means that it becomes very easy to become root on a system with that file. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]
* Aurelien Jarno: >> This doesn't seem correct to me. Is there any documentation giving a >> rationale for this ? Is there a way to change this locally ? > > I do not know enough about apparmor and its threat model to know if it > should be considered or not. From the glibc point of view, nothing can > be really done, it just obeys the AT_SECURE flag passed by the kernel. > > Now looking at apparmor.d(5), it seems it *might* be controlled by the > change_profile option with the safe and unsafe mode. But I don't speak > apparmor fluently enough to actually know how to introduce that option > in a profile. I think LSMs can nowadays also express security transitions that trust the execution environment, that is, that they add more restrictions instead of increasing privileges. I believe we use this with SELinux, so that these transitions to do not cause AT_SECURE to be set. Maybe this is something that apparmor could do as well? Thanks, Florian