** Changed in: linux (Ubuntu Noble)
       Status: New => Triaged

** Changed in: linux (Ubuntu Oracular)
       Status: New => Triaged

** Changed in: linux (Ubuntu Plucky)
       Status: New => Triaged

-- 
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:
  Triaged
Status in apparmor source package in Noble:
  New
Status in linux source package in Noble:
  Triaged
Status in apparmor source package in Oracular:
  New
Status in linux source package in Oracular:
  Triaged
Status in apparmor source package in Plucky:
  New
Status in linux source package in Plucky:
  Triaged

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

Reply via email to