* PSI poll() support for unprivileged users @ 2020-04-24 15:38 Chris Down 2020-04-24 19:43 ` Suren Baghdasaryan 0 siblings, 1 reply; 5+ messages in thread From: Chris Down @ 2020-04-24 15:38 UTC (permalink / raw) To: Suren Baghdasaryan; +Cc: Johannes Weiner, Peter Zijlstra, linux-kernel Hi Suren, I noticed that one restriction of the PSI poll() interface is that currently only root can set up new triggers. Talking to Johannes, it seems the reason for this was that you end up with a realtime kernel thread for every cgroup where a trigger is set, and this could be used by unprivileged users to sap resources. I'm building a userspace daemon for desktop users which notifies based on pressure events, and it's particularly janky to ask people to run such a notifier as root: the notification mechanism is usually tied to the user's display server auth, and the surrounding environment is generally pretty important to maintain. In addition to this, just in general this doesn't feel like the kind of feature that by its nature needs to be restricted to root -- it seems reasonable that there would be unprivileged users which want to use this, and that not using RT threads would be acceptable in that scenario. Have you considered making the per-cgroup RT threads optional? If the processing isn't done in the FIFO kthread for unprivileged users, I think it should be safe to allow them to write to pressure files (perhaps with some additional limits or restrictions on things like the interval, as needed). Thanks! Chris ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PSI poll() support for unprivileged users 2020-04-24 15:38 PSI poll() support for unprivileged users Chris Down @ 2020-04-24 19:43 ` Suren Baghdasaryan 2020-04-24 22:46 ` Suren Baghdasaryan 0 siblings, 1 reply; 5+ messages in thread From: Suren Baghdasaryan @ 2020-04-24 19:43 UTC (permalink / raw) To: Chris Down; +Cc: Johannes Weiner, Peter Zijlstra, LKML On Fri, Apr 24, 2020 at 8:39 AM Chris Down <chris@chrisdown.name> wrote: > > Hi Suren, Hi Chris, > > I noticed that one restriction of the PSI poll() interface is that currently > only root can set up new triggers. Talking to Johannes, it seems the reason for > this was that you end up with a realtime kernel thread for every cgroup where a > trigger is set, and this could be used by unprivileged users to sap resources. > This reasoning is correct and IIRC the enforcement of this is just the way /proc/pressure files are created: proc_create("pressure/io", 0, NULL, &psi_io_fops); proc_create("pressure/memory", 0, NULL, &psi_memory_fops); proc_create("pressure/cpu", 0, NULL, &psi_cpu_fops); IOW there are no additional capability checks performed on the PSI trigger users. > I'm building a userspace daemon for desktop users which notifies based on > pressure events, and it's particularly janky to ask people to run such a > notifier as root: the notification mechanism is usually tied to the user's > display server auth, and the surrounding environment is generally pretty > important to maintain. In addition to this, just in general this doesn't feel > like the kind of feature that by its nature needs to be restricted to root -- > it seems reasonable that there would be unprivileged users which want to use > this, and that not using RT threads would be acceptable in that scenario. For these cases you can provide a userspace privileged daemon that will relay pressure notifications to its unprivileged clients. This is what we do on Android - Android Management Server registers its PSI triggers and then relays low memory notifications to unprivileged apps. Another approach is taken by Android Low Memory Killer Daemon (lmkd) which is an unprivileged process but registers its PSI triggers. The trick is that the init process executes "chmod 0664 /proc/pressure/memory" from its init script and further restrictions are enforced by selinux policy granting only LMKD write access to this file. Would any of these options work for you? > Have you considered making the per-cgroup RT threads optional? If the > processing isn't done in the FIFO kthread for unprivileged users, I think it > should be safe to allow them to write to pressure files (perhaps with some > additional limits or restrictions on things like the interval, as needed). I didn't consider that as I viewed memory condition tracking that consumes kernel resources as being potentially exploitable. RT threads did make that more of an issue but even without them I'm not sure we should allow unprivileged processes to create unlimited numbers of triggers each of which is not really free. > > Thanks! > > Chris Thanks, Suren. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PSI poll() support for unprivileged users 2020-04-24 19:43 ` Suren Baghdasaryan @ 2020-04-24 22:46 ` Suren Baghdasaryan 2020-04-28 11:34 ` Chris Down 0 siblings, 1 reply; 5+ messages in thread From: Suren Baghdasaryan @ 2020-04-24 22:46 UTC (permalink / raw) To: Chris Down; +Cc: Johannes Weiner, Peter Zijlstra, LKML On Fri, Apr 24, 2020 at 12:43 PM Suren Baghdasaryan <surenb@google.com> wrote: > > On Fri, Apr 24, 2020 at 8:39 AM Chris Down <chris@chrisdown.name> wrote: > > > > Hi Suren, > > Hi Chris, > > > > > I noticed that one restriction of the PSI poll() interface is that currently > > only root can set up new triggers. Talking to Johannes, it seems the reason for > > this was that you end up with a realtime kernel thread for every cgroup where a > > trigger is set, and this could be used by unprivileged users to sap resources. > > > > This reasoning is correct and IIRC the enforcement of this is just the > way /proc/pressure files are created: > > proc_create("pressure/io", 0, NULL, &psi_io_fops); > proc_create("pressure/memory", 0, NULL, &psi_memory_fops); > proc_create("pressure/cpu", 0, NULL, &psi_cpu_fops); > > IOW there are no additional capability checks performed on the PSI > trigger users. > > > I'm building a userspace daemon for desktop users which notifies based on > > pressure events, and it's particularly janky to ask people to run such a > > notifier as root: the notification mechanism is usually tied to the user's > > display server auth, and the surrounding environment is generally pretty > > important to maintain. In addition to this, just in general this doesn't feel > > like the kind of feature that by its nature needs to be restricted to root -- > > it seems reasonable that there would be unprivileged users which want to use > > this, and that not using RT threads would be acceptable in that scenario. > > For these cases you can provide a userspace privileged daemon that > will relay pressure notifications to its unprivileged clients. This is > what we do on Android - Android Management Server registers its PSI > triggers and then relays low memory notifications to unprivileged > apps. > Another approach is taken by Android Low Memory Killer Daemon (lmkd) > which is an unprivileged process but registers its PSI triggers. The > trick is that the init process executes "chmod 0664 > /proc/pressure/memory" from its init script and further restrictions > are enforced by selinux policy granting only LMKD write access to this > file. > > Would any of these options work for you? > > > Have you considered making the per-cgroup RT threads optional? If the > > processing isn't done in the FIFO kthread for unprivileged users, I think it > > should be safe to allow them to write to pressure files (perhaps with some > > additional limits or restrictions on things like the interval, as needed). > > I didn't consider that as I viewed memory condition tracking that > consumes kernel resources as being potentially exploitable. RT threads > did make that more of an issue but even without them I'm not sure we > should allow unprivileged processes to create unlimited numbers of > triggers each of which is not really free. Thinking some more about this. LMKD in the above-mentioned usecase is not a privileged process but it is granted access to PSI triggers by a privileged init process+sepolicy and it needs RT threads to react to memory pressure promptly without being preempted. If we allow only the privileged users to have RT threads for PSI triggers then that requirement would break this scenario and LMKD won't be able to use RT threads. > > > > > Thanks! > > > > Chris > > Thanks, > Suren. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PSI poll() support for unprivileged users 2020-04-24 22:46 ` Suren Baghdasaryan @ 2020-04-28 11:34 ` Chris Down 2020-04-28 18:28 ` Suren Baghdasaryan 0 siblings, 1 reply; 5+ messages in thread From: Chris Down @ 2020-04-28 11:34 UTC (permalink / raw) To: Suren Baghdasaryan; +Cc: Johannes Weiner, Peter Zijlstra, LKML Hey Suren, Suren Baghdasaryan writes: >> > I'm building a userspace daemon for desktop users which notifies based on >> > pressure events, and it's particularly janky to ask people to run such a >> > notifier as root: the notification mechanism is usually tied to the user's >> > display server auth, and the surrounding environment is generally pretty >> > important to maintain. In addition to this, just in general this doesn't feel >> > like the kind of feature that by its nature needs to be restricted to root -- >> > it seems reasonable that there would be unprivileged users which want to use >> > this, and that not using RT threads would be acceptable in that scenario. >> >> For these cases you can provide a userspace privileged daemon that >> will relay pressure notifications to its unprivileged clients. This is >> what we do on Android - Android Management Server registers its PSI >> triggers and then relays low memory notifications to unprivileged >> apps. >> Another approach is taken by Android Low Memory Killer Daemon (lmkd) >> which is an unprivileged process but registers its PSI triggers. The >> trick is that the init process executes "chmod 0664 >> /proc/pressure/memory" from its init script and further restrictions >> are enforced by selinux policy granting only LMKD write access to this >> file. >> >> Would any of these options work for you? Hmm, I think these are reasonable options when you have control over the system, but not so great if you don't. For example, I want to get pressure notifications for my logind seat, but that doesn't necessarily imply that I have administrative access to the machine. >> > Have you considered making the per-cgroup RT threads optional? If the >> > processing isn't done in the FIFO kthread for unprivileged users, I think it >> > should be safe to allow them to write to pressure files (perhaps with some >> > additional limits or restrictions on things like the interval, as needed). >> >> I didn't consider that as I viewed memory condition tracking that >> consumes kernel resources as being potentially exploitable. RT threads >> did make that more of an issue but even without them I'm not sure we >> should allow unprivileged processes to create unlimited numbers of >> triggers each of which is not really free. There's precedent for other similar issues like this in the kernel, eg. rates for some ICMP packets, where we enforce a static limit in the kernel for unprivileged users. I'd imagine we can do something similar here, too. >Thinking some more about this. LMKD in the above-mentioned usecase is >not a privileged process but it is granted access to PSI triggers by a >privileged init process+sepolicy and it needs RT threads to react to >memory pressure promptly without being preempted. If we allow only the >privileged users to have RT threads for PSI triggers then that >requirement would break this scenario and LMKD won't be able to use RT >threads. Well, fiddlesticks :-) If we needed to have both, I don't know what the interface would look like, but yes, it sounds overcomplicated. I'll think about it some more. Thanks, Chris ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PSI poll() support for unprivileged users 2020-04-28 11:34 ` Chris Down @ 2020-04-28 18:28 ` Suren Baghdasaryan 0 siblings, 0 replies; 5+ messages in thread From: Suren Baghdasaryan @ 2020-04-28 18:28 UTC (permalink / raw) To: Chris Down; +Cc: Johannes Weiner, Peter Zijlstra, LKML On Tue, Apr 28, 2020 at 4:34 AM Chris Down <chris@chrisdown.name> wrote: > > Hey Suren, > > Suren Baghdasaryan writes: > >> > I'm building a userspace daemon for desktop users which notifies based on > >> > pressure events, and it's particularly janky to ask people to run such a > >> > notifier as root: the notification mechanism is usually tied to the user's > >> > display server auth, and the surrounding environment is generally pretty > >> > important to maintain. In addition to this, just in general this doesn't feel > >> > like the kind of feature that by its nature needs to be restricted to root -- > >> > it seems reasonable that there would be unprivileged users which want to use > >> > this, and that not using RT threads would be acceptable in that scenario. > >> > >> For these cases you can provide a userspace privileged daemon that > >> will relay pressure notifications to its unprivileged clients. This is > >> what we do on Android - Android Management Server registers its PSI > >> triggers and then relays low memory notifications to unprivileged > >> apps. > >> Another approach is taken by Android Low Memory Killer Daemon (lmkd) > >> which is an unprivileged process but registers its PSI triggers. The > >> trick is that the init process executes "chmod 0664 > >> /proc/pressure/memory" from its init script and further restrictions > >> are enforced by selinux policy granting only LMKD write access to this > >> file. > >> > >> Would any of these options work for you? > > Hmm, I think these are reasonable options when you have control over the > system, but not so great if you don't. For example, I want to get pressure > notifications for my logind seat, but that doesn't necessarily imply that I > have administrative access to the machine. > > >> > Have you considered making the per-cgroup RT threads optional? If the > >> > processing isn't done in the FIFO kthread for unprivileged users, I think it > >> > should be safe to allow them to write to pressure files (perhaps with some > >> > additional limits or restrictions on things like the interval, as needed). > >> > >> I didn't consider that as I viewed memory condition tracking that > >> consumes kernel resources as being potentially exploitable. RT threads > >> did make that more of an issue but even without them I'm not sure we > >> should allow unprivileged processes to create unlimited numbers of > >> triggers each of which is not really free. > > There's precedent for other similar issues like this in the kernel, eg. rates > for some ICMP packets, where we enforce a static limit in the kernel for > unprivileged users. I'd imagine we can do something similar here, too. > > >Thinking some more about this. LMKD in the above-mentioned usecase is > >not a privileged process but it is granted access to PSI triggers by a > >privileged init process+sepolicy and it needs RT threads to react to > >memory pressure promptly without being preempted. If we allow only the > >privileged users to have RT threads for PSI triggers then that > >requirement would break this scenario and LMKD won't be able to use RT > >threads. > > Well, fiddlesticks :-) > > If we needed to have both, I don't know what the interface would look like, but > yes, it sounds overcomplicated. I'll think about it some more. Yeah, the only idea I could come up with was to tie RT thread usage to some selinux policy instead of using file permissions or being root. But I have very little experience with selinux to tell you whether there might be issues with such an approach. > > Thanks, > > Chris ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-04-28 18:29 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-24 15:38 PSI poll() support for unprivileged users Chris Down 2020-04-24 19:43 ` Suren Baghdasaryan 2020-04-24 22:46 ` Suren Baghdasaryan 2020-04-28 11:34 ` Chris Down 2020-04-28 18:28 ` Suren Baghdasaryan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.