On Wed, Jun 12, 2024 at 11:54 PM John Johansen <john.johansen@xxxxxxxxxxxxx> wrote: > On 6/12/24 10:29, Paul Moore wrote: > > On Wed, Jun 12, 2024 at 4:15 AM Jonathan Calmels <jcalmels@xxxxxxxx> wrote: > >> On Tue, Jun 11, 2024 at 06:38:31PM GMT, Paul Moore wrote: > >>> On Tue, Jun 11, 2024 at 6:15 PM Jonathan Calmels <jcalmels@xxxxxxxx> wrote: > > > > ... > > > >>>> Arguably, if we do want fine-grained userns policies, we need LSMs to > >>>> influence the userns capset at some point. > >>> > >>> One could always use, or develop, a LSM that offers additional > >>> controls around exercising capabilities. There are currently four > >>> in-tree LSMs, including the capabilities LSM, which supply a > >>> security_capable() hook that is used by the capability-based access > >>> controls in the kernel; all of these hook implementations work > >>> together within the LSM framework and provide an additional level of > >>> control/granularity beyond the existing capabilities. > >> > >> Right, but the idea was to have a simple and easy way to reuse/trigger > >> as much of the commoncap one as possible from BPF. If we're saying we > >> need to reimplement and/or use a whole new framework, then there is > >> little value. > > > > I can appreciate how allowing direct manipulation of capability bits > > from a BPF LSM looks attractive, but my hope is that our discussion > > here revealed that as you look deeper into making it work there are a > > number of pitfalls which prevent this from being a safe option for > > generalized systems. > > > >> TBH, I don't feel strongly about this, which is why it is absent from > >> v1. However, as John pointed out, we should at least be able to modify > >> the blob if we want flexible userns caps policies down the road. > > > > As discussed in this thread, there are existing ways to provide fine > > grained control over exercising capabilities that can be safely used > > within the LSM framework. I don't want to speak to what John is > > envisioning, but he should be aware of these mechanisms, and if I > > recall he did voice a level of concern about the same worries I > > mentioned. > > > > sorry, I should have been more clear. I envision LSMs being able to > update their own state in the userns hook. Ah, okay, yes, that seems reasonable; although like any other change, until we have an in-tree user we should just leave it as-is. -- paul-moore.com
