re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
what's the use-case for disabling encrypted swap later? i'd argue we should avoid kauth for this and simply disable it always as i've been unable to think of any use case that is the only solution. .mrg.
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
> I think everybody believes that regardless of securelevel, root > should be able to enable encrypted swap. But probably almost > everyone thinks regular users should not be allowed to enable it. (Throughout the following, I'm using "root" as shorthand for "a user without suitable privilege". I think that, like most Unices, NetBSD makes privilege more all-or-nothing of a thing than would be ideal, but that is a completely separate issue, probably coloured by my having gone through much of my larval phase under VMS.) I think that - ideally - regular users should be able to enable encrypted swap _for their own pages_. This is not done for reasons unrelated to the abstract correctness of the idea - mostly, I suspect, that it involves a significant increase in administrative overhead at runtime (tracking ownership of every page in a way visible to the swap code). Furthermore, "the" owner of a page may be unclear in a few circumstances. These obstacles could be overcome, in principle. Is it worth it? In my opinion, for NetBSD, it is not. But it's because the gain is not worth the implementation effort, not because it's something that would conceptually be a Bad Thing. I do feel that it would be excessive for non-root user X to be able to enable encrypted swap for user Y's pages. I've been unable to justify this feeling, though; that is, I've been unable to come up with a thing which that would break but which I think ought to work. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
Alexander Nasonov writes: > Greg Troxel wrote: >> Kamil Rytarowski writes: >> >> > Is it possible to avoid negation in the name? >> > >> > KAUTH_SYSTEM_ENABLE_SWAP_ENCRYPTION >> >> I think the point is to have one permission to enable it, which is >> perhaps just regular root, and another to disable it if securelevel is >> elevated. >> >> So perhaps there should be two names, one to enable, one to disable. > > Kauth is about security rather than speed or convenience. Disabling > encryption may improve speed but it definitely degrades your security > level. So, you can enable vm.swap_encrypt at any level but you can't > disable it if you care about security. I understand that. But there's still a question of "should there be a KAUTH name for enabling as well as disabling", separate from "what should the rules be". I think everybody believes that regardless of securelevel, root should be able to enable encrypted swap. But probably almost everyone thinks regular users should not be allowed to enable it. I realize we have a lot of "root can", and that extending kauth to make everything separate is almost certainly too much. But when disabling is a big deal, I think it makes sense to add names for both enabling and disabling, to make that intent clearer in the sources. But, I don't think this is that important, and a comment would do.
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
Greg Troxel wrote: > Kamil Rytarowski writes: > > > Is it possible to avoid negation in the name? > > > > KAUTH_SYSTEM_ENABLE_SWAP_ENCRYPTION > > I think the point is to have one permission to enable it, which is > perhaps just regular root, and another to disable it if securelevel is > elevated. > > So perhaps there should be two names, one to enable, one to disable. Kauth is about security rather than speed or convenience. Disabling encryption may improve speed but it definitely degrades your security level. So, you can enable vm.swap_encrypt at any level but you can't disable it if you care about security. -- Alex
