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 -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.
