[Bug 176301] Re: Should provide a flag to disable ptrace()/LD_PRELOAD
Ah, Kees is right. I had this in my mind when I created the original approach with setgid noptrace binaries [1] [2], since a user cannot copy setgid binaries with keeping the sgid bit, and the programs could check whether they are setgid. Seems I failed to write this down explicitly, and thus just forgot about this when the Debian guys convinced me to not use this. So I think we are back to using prctl(SET_DUMPABLE, 0). It is subject to race conditions, but then the entire desktop security model is subject to all sorts of threats (spoofing being the most important one), so it's a reasonable compromise. I'll close this now. Sorry for the noise, and thanks for reminding me. :) [1] https://wiki.ubuntu.com/DesktopTeam/Specs/PolicyKitIntegration [2] http://lists.debian.org/debian-devel/2007/12/msg00216.html ** Changed in: apparmor (Ubuntu) Status: New = Invalid -- Should provide a flag to disable ptrace()/LD_PRELOAD https://bugs.launchpad.net/bugs/176301 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 176301] Re: Should provide a flag to disable ptrace()/LD_PRELOAD
Actually, AA already has a way to specify that LD_PRELOAD (and a number of other env variables like that) should be cleared on exec. It's definitely non-intuitive, but that's the distinction between Px and px (and Ux and ux) in the profile language. When a Px rule is used to grant execute permission, the bprm_secureexec lsm hook is used to signal to glibc to that a secure exec is required. glibc then strips LD_PRELOAD and does some other similar sanitization of the environment while launching the new process. I don't remember the full list of things that are done when a secure exec is requested. Personally, I think Px (or a clearer syntax version) should be the default, but a number of wrapper scripts rely on setting LD_PRELOAD or LD_LIBRARY_PATH and it's tricky to tell why things are failing in that case. I don't know if Ix is a valid cleaned variation of the ix permission, but I'm not sure how much benefit that would bring anyway. -- Should provide a flag to disable ptrace()/LD_PRELOAD https://bugs.launchpad.net/bugs/176301 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 176301] Re: Should provide a flag to disable ptrace()/LD_PRELOAD
Hi, Jesse Michael [2007-12-14 8:08 -]: Actually, AA already has a way to specify that LD_PRELOAD (and a number of other env variables like that) should be cleared on exec. Right, I know about Px etc., but that doesn't disable ptrace(), does it? Thanks, Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org -- Should provide a flag to disable ptrace()/LD_PRELOAD https://bugs.launchpad.net/bugs/176301 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 176301] Re: Should provide a flag to disable ptrace()/LD_PRELOAD
As long as PolicyKit requires the requesting application be in /usr/bin/whatever, this should work -- trying to confine processes from AA when starting from an unconfined process tends not to work very well (due to avoiding protections with hardlinks, for example). -- Should provide a flag to disable ptrace()/LD_PRELOAD https://bugs.launchpad.net/bugs/176301 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 176301] Re: Should provide a flag to disable ptrace()/LD_PRELOAD
Both of those flags would be easy to implement, the question is it worth it? As Kees pointed out an unconfined user can easily circumvent policy attachment and thus the flags that AppArmor would be enforcing. There are four cases I can see this working in: - trusted start up of deamon, only worried about ptrace attack on it. In this case we need to be able to stop an unconfined user process from ptraceing the deamon - app launched by trusted process that relies mandates the application start from a fixed location (eg. /usr/bin/whatever) - app is launched by a wrapper script in a profile that enforces the launch location. - confine the user The 1st case is really being concerned about ptrace attacks from something that gets compromised after login. The 2nd and 3rd are ways of preventing something that is compromised from circumventing the protections. The last one is not trusting the user, and can be done quite well with the most recent version of apparmor (not in gutsy). In general I like the idea of adding some flags to facilitate this, how did you envision the flags being set up and what are some more specific use cases (examples). Basically I am looking for design cues, as deciding how to express it is going to be the hardest point of implementing it. -- Should provide a flag to disable ptrace()/LD_PRELOAD https://bugs.launchpad.net/bugs/176301 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
