On Tue, Oct 17, 2023 at 01:34:35AM -0700, Jeff Xu wrote: > > > types: bit mask to specify which syscall to seal, currently they are: > > > MM_SEAL_MSEAL 0x1 > > > MM_SEAL_MPROTECT 0x2 > > > MM_SEAL_MUNMAP 0x4 > > > MM_SEAL_MMAP 0x8 > > > MM_SEAL_MREMAP 0x10 > > > > I don't understand why we want this level of granularity. The OpenBSD > > and XNU examples just say "This must be immutable*". For values of > > immutable that allow downgrading access (eg RW to RO or RX to RO), > > but not upgrading access (RW->RX, RO->*, RX->RW). > > > > > Each bit represents sealing for one specific syscall type, e.g. > > > MM_SEAL_MPROTECT will deny mprotect syscall. The consideration of bitmask > > > is that the API is extendable, i.e. when needed, the sealing can be > > > extended to madvise, mlock, etc. Backward compatibility is also easy. > > > > Honestly, it feels too flexible. Why not just two flags to mprotect() > > -- PROT_IMMUTABLE and PROT_DOWNGRADABLE. I can see a use for that -- > > maybe for some things we want to be able to downgrade and for other > > things, we don't. > > > Having a seal type per syscall type helps to add the feature incrementally. > Applications also know exactly what is sealed. You're trying to portray a disadvantage as an advantage, This is the seccomp disease, only worse because you're trying to deny individual syscalls instead of building up a list of permitted syscalls. If we introduce a new syscall tomorrow which can affect VMAs, we'll then make it the application's fault for not disabling that new syscall. That's terrible design! > I'm not against types such as IMMUTABLE and DOWNGRADEABLE, if we > can define what it seals precisely. As Jann pointed out, there have > other scenarios that potentially affect IMMUTABLE. Implementing all thoses > will take time. And if we missed a case, we could introduce backward > compatibility issues to the application. Bitmask will solve this nicely, i.e. > application will need to apply the newly added sealing type explicitly. It is your job to do this. You seem to have taken the attitude that you will give the Chrome team exactly what they asked for instead of trying to understand their requirements and give them what they need. And don't send a v2 before discussion of v1 has come to an end. It uselessly fragments the discussion.
