Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
On Sun, May 17, 2020 at 12:38:41PM -0400, Mouse wrote: > Furthermore, "the" owner of a page > may be unclear in a few circumstances. This is a nontrivial problem... a good solution to it would be useful even just for accounting purposes. -- David A. Holland dholl...@netbsd.org
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
mar...@duskware.de (Martin Husemann) writes: >I agree with both. Leave it an admin decision (and maybe default to >"encrypt"). Also assume that it is possible to complete enough of /etc/rc.d >without any swapping ;-} so a simple setting in /etc/sysctl.conf will do. If you don't allow to disable encryption, the code could be simplified to not track encrypted and non-ecnrypted parts of the swap. Instead the setting should be fixed before swap is enabled. Otherwise you still end with unencrypted bits in the swap partition. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
On Mon, May 18, 2020 at 06:21:10PM -0400, Mouse wrote: > >> Always encrypted swap would be even better but ... slow machines. > > Compared to the time required to put the pages out to disk? > > That comparison is relevant only if the system has nothing better to do > than wait for the page out/in. A few systems probably don't. Most, I > suspect, do, and if there _is_ something else the CPU could usefully be > doing, I suspect spending the (scarce) cycles there is preferable. > > At least for most systems. There certainly is a place for allowing the > admin to insist on encrypted swap even on slow machines. I agree with both. Leave it an admin decision (and maybe default to "encrypt"). Also assume that it is possible to complete enough of /etc/rc.d without any swapping ;-} so a simple setting in /etc/sysctl.conf will do. I can run tests on slow + small memory machines (but not really sure what a good test would be - maybe compiling a few things with MAKE_JOBS >= 2 from pkgsrc?). Martin
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
>> Always encrypted swap would be even better but ... slow machines. > Compared to the time required to put the pages out to disk? That comparison is relevant only if the system has nothing better to do than wait for the page out/in. A few systems probably don't. Most, I suspect, do, and if there _is_ something else the CPU could usefully be doing, I suspect spending the (scarce) cycles there is preferable. At least for most systems. There certainly is a place for allowing the admin to insist on encrypted swap even on slow machines. /~\ 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
> Date: Mon, 18 May 2020 17:51:51 -0400 > From: Thor Lancelot Simon > > On Mon, May 18, 2020 at 09:08:14PM +0100, Alexander Nasonov wrote: > > matthew green wrote: > > > what's the use-case for disabling encrypted swap later? > > > > It might be too slow on some machines. > > > > > 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. > > > > Always encrypted swap would be even better but ... slow machines. > > Compared to the time required to put the pages out to disk? If anyone is concerned with the overhead of encryption on top of the cost of swapping to disk, we could: 1. Always prohibit disabling it for now -- no new kauth required. Wanna disable it, gotta reboot. 2. While it is off by default, measure the additional impact on slow machines of doing the bit of extra computation when we're already swapping. 3. Decide on the basis of (2) whether, if/when we later flip on vm.swap_encrypt=1 by default, to add a kauth to control whether it can be disabled at all, or whether to just always encrypt swap unconditionally and forget about the bad old days when we wrote ephemeral memory out to nonvolatile storage in cleartext. > Could try chacha8. This does not work on its face, because we may need to encrypt many different pages over time in the same swap slot, and the only additional input available is the swap slot number. That's why I chose AES-CBC with iv=AES_k(slotno). To use ChaCha8 with the same key and same slot number twice we would need to maintain a nonce to distinguish the two versions, which adds extra storage when we're already swapping. We could improve on it by using a better wide-block tweakable PRP construction than CBC, and by using a better primitive than AES, but that would require slightly more work and thought that may not be worthwhile. (My calculus last weekend was that I wanted to make swap encryption JFW, preferably some time over a decade ago. My calculus for a rainy day later on depends on the results of measurement.)
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
On Mon, May 18, 2020 at 09:08:14PM +0100, Alexander Nasonov wrote: > matthew green wrote: > > what's the use-case for disabling encrypted swap later? > > It might be too slow on some machines. > > > 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. > > Always encrypted swap would be even better but ... slow machines. Compared to the time required to put the pages out to disk? Could try chacha8. -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will work, but because it is right." --Andrei Sakharov
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
matthew green wrote: > what's the use-case for disabling encrypted swap later? It might be too slow on some machines. > 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. Always encrypted swap would be even better but ... slow machines. -- Alex
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
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
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.
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
Is it possible to avoid negation in the name? KAUTH_SYSTEM_ENABLE_SWAP_ENCRYPTION On 17.05.2020 00:51, Paul Goyette wrote: > I'm not sure I like the name! > > Can you call it KAUTH_SYSTEM_DISABLE_SWAPENCRYPT ? That more > closely describes the action which is being controlled. > > > On Sat, 16 May 2020, Alexander Nasonov wrote: > >> Attached patch adds KAUTH_SYSTEM_UNENCRYPTED_SWAP and >> it forbids changing vm.swap_encrypt from 1 to 0 when >> securelevel > 0. >> >> If there are no objections, I'm going to commit it tomorrow. >> >> -- >> Alex >> >> >> !DSPAM:5ec06ddb24841398742664! >> > > ++--+---+ > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > ++--+---+ signature.asc Description: OpenPGP digital signature
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
m...@netbsd.org wrote: > No objections from me, but I feel like "will commit unless objected" > should be done on longer time scales. I spend way too much time on > netbsd and I still have some days I dont get to reading email for > whatever reason. It's a small change, we discussed it on source-changes-d and current-users already. I could have committed it without sending the patch but I introduce a new public constant and I wasn't very sure how to best name it. -- Alex
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
On Sat, May 16, 2020 at 11:53:02PM +0100, Alexander Nasonov wrote: > Attached patch adds KAUTH_SYSTEM_UNENCRYPTED_SWAP and > it forbids changing vm.swap_encrypt from 1 to 0 when > securelevel > 0. > > If there are no objections, I'm going to commit it tomorrow. No objections from me, but I feel like "will commit unless objected" should be done on longer time scales. I spend way too much time on netbsd and I still have some days I dont get to reading email for whatever reason.
Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP
I'm not sure I like the name! Can you call it KAUTH_SYSTEM_DISABLE_SWAPENCRYPT ? That more closely describes the action which is being controlled. On Sat, 16 May 2020, Alexander Nasonov wrote: Attached patch adds KAUTH_SYSTEM_UNENCRYPTED_SWAP and it forbids changing vm.swap_encrypt from 1 to 0 when securelevel > 0. If there are no objections, I'm going to commit it tomorrow. -- Alex !DSPAM:5ec06ddb24841398742664! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
