This is close, but not full, solution to the problem. For reasons
currently unknown, the final shared link still gains E in GNU_STACK.
** Attachment added: klibc_1.5.7-4ubuntu2.debdiff
http://launchpadlibrarian.net/13099228/klibc_1.5.7-4ubuntu2.debdiff
--
apparmor broken after reboot on
klibc's run-init has GNU_STACK with E, so READ_IMPLIES_EXEC is passed
down to upstart and children.
** Also affects: klibc (Ubuntu)
Importance: Undecided
Status: New
** Changed in: apparmor (Ubuntu)
Status: New = Invalid
** Changed in: klibc (Ubuntu)
Assignee: (unassigned)
This bug was fixed in the package klibc - 1.5.7-4ubuntu2
---
klibc (1.5.7-4ubuntu2) hardy; urgency=low
* Add 30-drop-executable-stack.patch: do not generate executable
stack for ia32, so the READ_IMPLIES_EXEC does not get set for
children (LP: #202161).
-- Kees Cook
With cupsys 1.3.6-3ubuntu1 and apparmor 2.1+1075-0ubuntu6 on i386 with
2.6.24-12-generic (not a vm) I see:
Apr 2 08:01:45 mix kernel: [37412.733502] audit(1207144905.051:17):
operation=file_mmap request_mask=mr:: denied_mask=m::
name=/var/lib/misc/group.db pid=7152 profile=/usr/sbin/cupsd
This is a side effect of linux personalities. When booting on an ia32
machine hardy has the READ_IMPLIES_EXEC flag set in its personality.
This causes an mmap for read permission to also ask for PROT_EXEC, which
causes the extra 'm' request seen above. Ubuntu by default is mounting
several
sorry, I jumped the gun slightly and mis read a mount line and a piece
of code. The nosuid option does interact with this but is not whats
causing the clearing of the personality. Execution of any setuid binary
will cause the personality to get cleared, so using either su or sudo to
switch from
slapd has now been upgraded to have a modified profile that will work
around this difference. I am not sure if this is actually a bug, but
rather simply a difference in apparmor on different architectures.
--
apparmor broken after reboot on i386
https://bugs.launchpad.net/bugs/202161
You
