Public bug reported:
Even with fix
f7eb20525d44 UBUNTU: SAUCE: apparmor4.0.0 [96/99]: apparmor: fix prompt failing
during large down loads
large file operations that are redirected to prompt can still cause access
denials. The full source of the denials still needs to be investigated.
There are so far 2 identified sources.
1. Fixed hard timeout for a file prompt. Any prompt over 2 minutes in length
will be cancelled and denied.
a more dynamic keep alive/heart beat mechanism is needed.
2. There is an interrupt loop scenario where a prompt is woken up by an
interrupt, cancelled and ERESTARTSYS is returned to user space. In this case
the syscall is restarted but the old notification is cancelled and a new
notification is started, and sent to snapd. This can lead to multiple failure
scenarios depending on the interaction between snapd and apparmor caching
levels.
2a) If snapd gets an error and caches denial, this will cause a denial on the
outstanding prompt.
needs verification that there is no case where this can happen.
2b) If apparmor caches the failure, this will cause a denial on the
outstanding prompt
needs verification that there is no case where this can happen.
2c) It is possible to get into a restart loop between interrupt, new
notification request to snapd, and another interrupt before reply,
causing the notification to hang, or overloading snapd request queue
causing a timeout and subsequently failure 1.
This needs an interrupted request restart mechanism that will cache
the interrupted request and reuse the original request id.
3. Policy can be missing part file information, for a prompt allowed file.
Resulting in a denial for the part when the base file is allowed.
This can be handled by having a conditionally dependent rule, such
that when a specific file is allowed the matching pattern is
automatically allowed.
** Affects: apparmor (Ubuntu)
Importance: Undecided
Assignee: John Johansen (jjohansen)
Status: New
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: John Johansen (jjohansen)
Status: New
** Affects: apparmor (Ubuntu Noble)
Importance: Undecided
Assignee: John Johansen (jjohansen)
Status: New
** Affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Oracular)
Importance: Undecided
Assignee: John Johansen (jjohansen)
Status: New
** Affects: linux (Ubuntu Oracular)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Plucky)
Importance: Undecided
Assignee: John Johansen (jjohansen)
Status: New
** Affects: linux (Ubuntu Plucky)
Importance: Undecided
Assignee: John Johansen (jjohansen)
Status: New
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => John Johansen (jjohansen)
** Also affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Oracular)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Plucky)
Importance: Undecided
Assignee: John Johansen (jjohansen)
Status: New
** Also affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Changed in: apparmor (Ubuntu Noble)
Assignee: (unassigned) => John Johansen (jjohansen)
** Changed in: apparmor (Ubuntu Oracular)
Assignee: (unassigned) => John Johansen (jjohansen)
** Changed in: apparmor (Ubuntu Plucky)
Assignee: (unassigned) => John Johansen (jjohansen)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2089651
Title:
Prompt denial of large part files
Status in apparmor package in Ubuntu:
New
Status in linux package in Ubuntu:
New
Status in apparmor source package in Noble:
New
Status in linux source package in Noble:
New
Status in apparmor source package in Oracular:
New
Status in linux source package in Oracular:
New
Status in apparmor source package in Plucky:
New
Status in linux source package in Plucky:
New
Bug description:
Even with fix
f7eb20525d44 UBUNTU: SAUCE: apparmor4.0.0 [96/99]: apparmor: fix prompt
failing during large down loads
large file operations that are redirected to prompt can still cause access
denials. The full source of the denials still needs to be investigated.
There are so far 2 identified sources.
1. Fixed hard timeout for a file prompt. Any prompt over 2 minutes in length
will be cancelled and denied.
a more dynamic keep alive/heart beat mechanism is needed.
2. There is an interrupt loop scenario where a prompt is woken up by an
interrupt, cancelled and ERESTARTSYS is returned to user space. In this case
the syscall is restarted but the old notification is cancelled and a new
notification is started, and sent to snapd. This can lead to multiple failure
scenarios depending on the interaction between snapd and apparmor caching
levels.
2a) If snapd gets an error and caches denial, this will cause a denial on
the outstanding prompt.
needs verification that there is no case where this can happen.
2b) If apparmor caches the failure, this will cause a denial on the
outstanding prompt
needs verification that there is no case where this can happen.
2c) It is possible to get into a restart loop between interrupt, new
notification request to snapd, and another interrupt before reply,
causing the notification to hang, or overloading snapd request queue
causing a timeout and subsequently failure 1.
This needs an interrupted request restart mechanism that will
cache the interrupted request and reuse the original request id.
3. Policy can be missing part file information, for a prompt allowed file.
Resulting in a denial for the part when the base file is allowed.
This can be handled by having a conditionally dependent rule, such
that when a specific file is allowed the matching pattern is
automatically allowed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2089651/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
