libreport version: 2.0.8 executable: /usr/bin/python hashmarkername: setroubleshoot kernel: 3.3.0-0.rc2.git4.1.fc17.x86_64 reason: SELinux is preventing /usr/libexec/postfix/local from 'sys_ptrace' accesses on the None /var/spool/postfix/active/1C60C6EC7. time: lun. 06 févr. 2012 22:54:09 CET description: Text file, 32488 bytes
Created attachment 559763 [details] File: description
*** Bug 787843 has been marked as a duplicate of this bug. ***
*** Bug 787845 has been marked as a duplicate of this bug. ***
*** Bug 788038 has been marked as a duplicate of this bug. ***
*** Bug 787844 has been marked as a duplicate of this bug. ***
*** Bug 788174 has been marked as a duplicate of this bug. ***
*** Bug 788175 has been marked as a duplicate of this bug. ***
shouldn't the summary reflect, that this bugs collects all/most/some 'sys_ptrace-is-now-forbidden' bugs?
Well this is really not related to that issue. These are being caused because the kernel is requiring sys_ptrace access for any process that tries to read the link file /proc/PID/exe, where the PID is not the same as the process trying to read it. This link points to the path of the executable used to start the process. I believe that the kernel should be requiring DAC_READ_SEARCH and not SYS_PTRACE for this access.
Proposing this as NTH for Alpha: it'll cause massive AVC spam and -88 fixes it but missed the freeze. Basically any time something writes to syslog you'll get an AVC, according to dwalsh. So if we don't fix this we might wind up with a lot of annoying dupes filed from Alpha. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
+1 NTH
+1 NTH This does not backout https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
three +1s, plus me: accepting as NTH. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 790330 has been marked as a duplicate of this bug. ***
+1 NTH This does not backout https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace No I will blog on this soon. My current understanding of sys_ptrace is ... If any process tries to look at information about a process with a different UID inside of the /proc file system, it will require sys_ptrace access. (Although not all fields are protected by it.) If you tried to actually look at the memory information about a different process, this requires ptrace. So any process that will be running as root and expect the ps/killall/pidof type commands to work will need the sys_ptrace capability. From an SELinux point of view this is allow X_t self:capability sys_ptrace; If a process wants to also examine/modify the memory of any other process other then its own process (/proc/self) this will require the process ptrace access. allow X_t Y_t:process ptrace; or allow X_t self:process ptrace; This means we can block all ptrace, but blocking sys_ptrace is impractical. What is strange, is up until the latest kernels, I did not see this issue.
Fix looks good in RC2, I see no sys_ptrace denials on boot. When I did a network install (so got the older selinux-policy), I saw a ton. So setting VERIFIED, we still need to push -88 to stable. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-89 went stable, so we can close this now. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers