On Fri, May 22, 2020 at 5:00 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > H alli, > > while debugging an AVC that started popping up after a change of > default RLIMIT_NOFILE on RHEL-8, I came across the SELinux setrlimit > check, where I don't quite understand what is the motivation for > requiring permission also for lowering the hard limit. The code > comments [1] [2], as well as the prlimit hook's commit message [3], > explain that the hard limit is used as the reset value when inheriting > the parent's limits is not allowed and I understand that raising a > task's hard limit can have unwanted security consequences due to that, > but I don't quite see what's the concern with lowering it. Yes, the > child process would indirectly "inherit" this limit even when > inheriting is denied, but it could only get a lower value than > otherwise, which doesn't sound like a security risk. > > In a situation where setrlimit is denied by default, this seems to > "punish" the processes that want to play fair and lower their limits > to the minimum they need. So what would be the security implications > of always allowing a process to lower its hard limits? > > Thanks, > > [1] https://elixir.bootlin.com/linux/latest/source/security/selinux/hooks.c#L4092 > [2] https://elixir.bootlin.com/linux/latest/source/security/selinux/hooks.c#L2465 > [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=791ec491c372f49cea3ea7a7143454a9023ac9d4 Originally introduced here: https://lore.kernel.org/lkml/1072714025.845.92.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/ The threat scenario is one where a process lowers its limit prior to a domain-changing execve() in order to induce a failure in the new program that leads to a security vulnerability. Specific motivating example: https://lore.kernel.org/selinux/Pine.LNX.4.33.0306060554430.10200-300000@xxxxxxxxxxxxxxxxxx/ That said, I'm not sure that this check (or rlimitinh) are effectively leveraged in Linux (or Android) today, so it may be that it isn't providing practical benefit. Some analysis perhaps of existing policies and past CVEs (e.g. would/could it have made a difference) might be interesting.
