Mailinglist Archive: opensuse-bugs (8034 mails)
| < Previous | Next > |
[Bug 221567] apparmor causes kernel lockup if there is any audit backlog
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Mon, 11 Dec 2006 17:03:32 -0700 (MST)
- Message-id: <20061212000332.EC0C4F7B@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=221567
------- Comment #4 from seth.arnold@xxxxxxxxxx 2006-12-11 17:03 MST -------
We had an apparmor profile for netstat. (Several programs that we had provided
profiles for ran netstat and it made more sense to provide a netstat profile
for those clients, rather than granting them rights to netstat directly, for
long term maintenance.)
Between 10.1 and 10.2, the kernel's handling of /proc/pid/fd/* readlink
handling changed to require CAP_SYS_PTRACE. (While AppArmor can pass along
CAP_SYS_PTRACE, we simply return failure for confined processes in the .ptrace
security_ops callback.) This resulted in two audit messages being sent to LAF
for every filedescriptor that netstat would try to interrogate. And, in the
version of AppArmor in those kernels, we would also WARN_ON the return value
from LAF if it changed the error return value.
My understanding is that LAF would report ENOMEM or something similar when
running this test case, because a few dozen netstats running in parellel can
generate audit output far faster than auditd can log them to disk. When LAF
fills the available kernel address space (or physical memory) it will return
ENOMEM, and our module would log a backtrace.
This backtrace was intended to help us find changes in the locking -- since
many LSM calls are called under spinlock, we must use GFP_ATOMIC for many LAF
calls. This WARN_ON is simply a backtrace to help us locate no-longer-correct
callsites when problems crop up down the road.
It also serves to exacerbate the problem, as the extra load will not make
auditd log any faster...
To summarize: the backtrace is just a backtrace. No big deal. I believe it
might have been removed from newer kernels.
The ptrace problem is really unfortunate. We'll have to figure out something
here.
But the gist of the problem is that with apparmor an untrusted application can
generate audit events far faster than auditd can log them to disk. And the
resulting memory pressure brings the machine to the brink of disaster.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
------- Comment #4 from seth.arnold@xxxxxxxxxx 2006-12-11 17:03 MST -------
We had an apparmor profile for netstat. (Several programs that we had provided
profiles for ran netstat and it made more sense to provide a netstat profile
for those clients, rather than granting them rights to netstat directly, for
long term maintenance.)
Between 10.1 and 10.2, the kernel's handling of /proc/pid/fd/* readlink
handling changed to require CAP_SYS_PTRACE. (While AppArmor can pass along
CAP_SYS_PTRACE, we simply return failure for confined processes in the .ptrace
security_ops callback.) This resulted in two audit messages being sent to LAF
for every filedescriptor that netstat would try to interrogate. And, in the
version of AppArmor in those kernels, we would also WARN_ON the return value
from LAF if it changed the error return value.
My understanding is that LAF would report ENOMEM or something similar when
running this test case, because a few dozen netstats running in parellel can
generate audit output far faster than auditd can log them to disk. When LAF
fills the available kernel address space (or physical memory) it will return
ENOMEM, and our module would log a backtrace.
This backtrace was intended to help us find changes in the locking -- since
many LSM calls are called under spinlock, we must use GFP_ATOMIC for many LAF
calls. This WARN_ON is simply a backtrace to help us locate no-longer-correct
callsites when problems crop up down the road.
It also serves to exacerbate the problem, as the extra load will not make
auditd log any faster...
To summarize: the backtrace is just a backtrace. No big deal. I believe it
might have been removed from newer kernels.
The ptrace problem is really unfortunate. We'll have to figure out something
here.
But the gist of the problem is that with apparmor an untrusted application can
generate audit events far faster than auditd can log them to disk. And the
resulting memory pressure brings the machine to the brink of disaster.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
| < Previous | Next > |