This bug was fixed in the package apparmor - 2.8.95~2430-0ubuntu5.2
---
apparmor (2.8.95~2430-0ubuntu5.2) trusty-proposed; urgency=medium
* debian/patches/php5-Zend_semaphore-lp1401084.patch: allow php5
abstraction access to Zend opcache files (LP: #1401084)
*
** Branch linked: lp:ubuntu/trusty-proposed/rsyslog
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rsyslogd profile for different processes
** Branch linked: lp:ubuntu/trusty-proposed/apparmor
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rsyslogd profile for different processes
Oddly enough, I'm still seeing some variation of this error:
May 21 12:27:28 xeon kernel: [95104.918686] audit: type=1400
audit(1432225648.230:57): apparmor=DENIED operation=sendmsg
info=Failed name lookup - disconnected path error=-13
profile=/usr/sbin/rsyslogd name=dev/log pid=3444 comm=logger
Simon, that is a different issue unrelated to this update. It is being
tracked in bug #1373070.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor
For the apparmor trusty SRU, I reproduced the failure with the source
for apparmor 2.8.95~2430-0ubuntu5.1 from trusty-updates with a hardware
enablement kernel and confirmed that apparmor 2.8.95~2430-0ubuntu5.2
addresses the issue. I also verified that the rest of the apparmor
regression tests
Here is the patch to address the apparmor userspace component of this
bug as part of a trusty SRU. It's already been addressed in utopic and
later.
** Patch added: tests-workaround_for_unix_socket_change-lp1425398.patch
This bug was fixed in the package rsyslog - 7.4.4-1ubuntu2.6
---
rsyslog (7.4.4-1ubuntu2.6) trusty-proposed; urgency=medium
* debian/usr.sbin.rsyslog: grant read access to /dev/log to cope with
behaviorial change of apparmor in utopic HWE kernel (LP: #1425398)
-- Steve
It seems that issue is gone with this fix.
1. Installed the package from trusty-proposed
# LANG=C apt-cache policy rsyslog
rsyslog:
Installed: 7.4.4-1ubuntu2.6
Candidate: 7.4.4-1ubuntu2.6
Version table:
*** 7.4.4-1ubuntu2.6 0
400 http://archive.ubuntu.com/ubuntu/
Works here too, thanks!
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor
ACK on the debdiff in comment #20. Uploaded for processing by the SRU
team. Thanks!
** Changed in: rsyslog (Ubuntu Trusty)
Status: Triaged = In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in
Hello Pavel, or anyone else affected,
Accepted rsyslog into trusty-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/rsyslog/7.4.4-1ubuntu2.6 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
** Description changed:
- Hi.
+ [rsyslog impact]
+ This bug prevents rsyslog from receiving all events from other services on
trusty when the utopic-hwe (and newer) kernels are used. The rsyslog SRU adds
an additional permission (read access to /dev/log) to the rsyslog apparmor
policy to allow
It turns out that there is a small bit of the AppArmor userspace that
needs to be addressed, the regression tests need to be slightly adjusted
to take the permissions change into account.
** Changed in: apparmor (Ubuntu Trusty)
Status: Invalid = In Progress
** Changed in: apparmor (Ubuntu
The issue here is that one end of the socket is an fs socket and the
other end is anonymous. When the check is done from the socket at the
anonymous end, the check is being dropped.
the patch is a backport of what is in utopic/vivid but is currently
untested. I am building a test kernel
**
John, what changes are needed kernel side to address this issue?
Attached is a debdiff to address the rsyslog policy side of things.
** Patch added: rsyslog_7.4.4-1ubuntu2.6.debdiff
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses rsyslogd profile for different processes - utopic HWE
Status in
Pavel, note that Steve closed the rsyslog/vivid task because that has
been fixed; the rsyslog/trusty task is still open, as are the kernel
portions of the bug.
Thanks
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor
This is fixed in the rsyslog policy in vivid; closing there.
** Changed in: rsyslog (Ubuntu Trusty)
Assignee: (unassigned) = Steve Beattie (sbeattie)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
The rsyslog apparmor policy is shipped in the rsyslog package, not
apparmor. Opening a task against rsyslog, closing the apparmor userspace
task.
** Also affects: rsyslog (Ubuntu)
Importance: Undecided
Status: New
** Changed in: apparmor (Ubuntu)
Status: Confirmed = Invalid
**
Also if you read comments of other Ubuntu _developers_, they are rather
confident that the bug is in Utopic HWE for Trusty
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
As I said before, I don't use Vivid, I use Trusty which is stated to be
supported until 2019!
The bug is against trusty, please don't close it as fixed in an non-LTS
release
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apparmor (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apparmor (Ubuntu Trusty)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Same problem here (Trusty+HWE kernel) and adding /dev/log r, to
/etc/apparmor.d/local/usr.sbin.rsyslogd does not help.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
So after looking into this more it looks like this is actually a bug in
the trusty kernel, that has been fixed on utopic.
Trusty needs a kernel patch and an update to its policy.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu
** Changed in: linux (Ubuntu Trusty)
Status: Incomplete = Confirmed
** Changed in: linux (Ubuntu)
Status: Incomplete = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Pavel,
okay thanks, this does sound like a bug in the kernel. I will look into
it more
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1425398
Title:
Apparmor uses
Are you using the apparmor user space from trusty or the utopic or
backport apparmor userspace?
When using the trusty userspace the HWE kernel should behave like the
trusty kernel, however when using a newer userspace with the HWE kernel
policy will need to be updated.
Ubuntu have chosen to not
John,
I'm using Ubuntu Trusty with Utopic HWE, so my apparmor is from Trusty.
I didn't install anything from backports or Utopic by hand to not mess package
system and LTS state of distribution.
But somehow the system does not behave like trusty.
Note that I've updated this system from 12.04 w/
There's a chance this is the AppArmor cross profile IPC check; when
one process performs an IPC operation with a second process, in
different profiles, both profiles have to allow the operation.
If my guess is right, these ought to be silenced by changing:
/dev/log wl,
to
/dev/log rwl,
in
Seth is correct,
when a message is sent across a unix based file socket their is a cross
check (one check for the sender, and another for the receiver). In this
case the receiving end of the message (rsyslogd) does not have the
correct permission (r perm).
The reason this is reported with the
First of all, Trusty kernel worked somehow differently. It didn't
complain for /dev/log.
Yes, my /etc/apparmor.d/usr.sbin.rsyslogd does not have 'r' for /dev/log:
/dev/log wl,
So does it mean that the rsyslog profile has to be patched for trusty?
Or at least some kind of
33 matches
Mail list logo
