Re: [solo5] Is dumpcore enabled
‐‐‐ Original Message ‐‐‐ On August 16, 2018 6:11 PM, Martin Lucina wrote: > On Wednesday, 15.08.2018 at 05:00, Adam Steen wrote: > > > Hi Martin > > I have complete the pull request [1], and was looking for further > > discussion from anyone who is interested. > > Thanks, I'll look into it, but it might take a week or so, currently > concentrating on the renaming/refactor for #172. > > It might be easier to do this after that is done as all the internal API > names will change. > > Cheers, > > -mato Hi Mato I think your right, lets do it after the rename/refactor, the code is there and i can use it, and i more things than time that i need to do. Cheers Adam
Re: [solo5] Is dumpcore enabled
On Wednesday, 15.08.2018 at 05:00, Adam Steen wrote: > Hi Martin > > I have complete the pull request [1], and was looking for further discussion > from anyone who is interested. Thanks, I'll look into it, but it might take a week or so, currently concentrating on the renaming/refactor for #172. It might be easier to do this after that is done as all the internal API names will change. Cheers, -mato
Re: [solo5] Is dumpcore enabled
‐‐‐ Original Message ‐‐‐ On 13 August 2018 1:47 AM, Martin Lucina wrote: > Hi Adam, > > apologies for the delayed reply, I've been on vacation. > > On Sunday, 22.07.2018 at 22:36, Adam Steen wrote: > > > Hi All > > After a quick discussion with Hannes and attempting to implement coredump > > on OpenBSD[1], i found there was no easy way to determine if use_coredump > > was true. ie coredump was enabled., > > I had to remove a tight pledge, privilege drop and chroot just to enable > > coredump, i wasn't sure it was worth it. Hannes suggested turning the > > security changes on or off if coredump was enabled, but we both couldn't > > find a easy way to do this. > > So i am posting here to get the discussion started about, what we can do to > > make this easier. > > The only things i could come up with, with the current code, was to disable > > the security if the dumpcore module was compile in (available). see [2] and > > [3]. > > I wanted to raise this discussion not around my coredump code but about > > determining which module(s) are enabled in the ukvm main/system code > > This is a good question. With the current model of determining modules to > enable at compile time, I would use the same approach for determining > whether or not to "drop privileges" (not sure what best to call this > functionality, suggestions please?). > > Specifically: > > 1. Add a compile-time #define, e.g. UKVM_DROP_PRIVILEGES. In a suitable > header, say ukvm/ukvm.h since that is included by all modules, define this > to 1 if not already defined. I.e. default to dropping privileges. > > 2. ukvm-configure can then manually add -DUKVM_DROP_PRIVILEGES=0 to CFLAGS > if dumpcore has been requested. > > 3. If UKVM_DROP_PRIVILEGES=1, you get the current behaviour in your code. > 4. If UKVM_DROP_PRIVILEGES=0, privilege dropping is disabled AND ukvm > prints a stern warning to this effect at startup, including something > about > not being recommended for production, etc. > > Separately from this, and with a view to adding some amount of privilege > dropping by default on other systems besides OpenBSD, I think that: > > 5. The privilege dropping code should be moved into its own top-level > function, e.g. ukvm_hv_drop_privileges(), which goes into ukvm_hv_.c. > > > 2. This function is clearly called from ukvm/ukvm_main.c, just before > entering the VCPU loop(?). This would also be where the #if printing the > warning if disabled (see (4) above) goes. > > As for what privileges should exactly be dropped on other OSes by default, > I need to think about that a bit more and will follow up during the week. > However, this should be enough to get you started. > > Would this approach work for you? Any other opinions? > > Cheers, > > -mato this approach works really well, i like it! I hope to have something along these lines this week! Cheers Adam
Re: [solo5] Is dumpcore enabled
Hi Adam, apologies for the delayed reply, I've been on vacation. On Sunday, 22.07.2018 at 22:36, Adam Steen wrote: > Hi All > > After a quick discussion with Hannes and attempting to implement coredump on > OpenBSD[1], i found there was no easy way to determine if use_coredump was > true. ie coredump was enabled., > > I had to remove a tight pledge, privilege drop and chroot just to enable > coredump, i wasn't sure it was worth it. Hannes suggested turning the > security changes on or off if coredump was enabled, but we both couldn't find > a easy way to do this. > > So i am posting here to get the discussion started about, what we can do to > make this easier. > > The only things i could come up with, with the current code, was to disable > the security if the dumpcore module was compile in (available). see [2] and > [3]. > > I wanted to raise this discussion not around my coredump code but about > determining which module(s) are enabled in the ukvm main/system code This is a good question. With the current model of determining modules to enable at compile time, I would use the same approach for determining whether or not to "drop privileges" (not sure what best to call this functionality, suggestions please?). Specifically: 1. Add a compile-time #define, e.g. UKVM_DROP_PRIVILEGES. In a suitable header, say ukvm/ukvm.h since that is included by all modules, define this to 1 if not already defined. I.e. default to dropping privileges. 2. ukvm-configure can then manually add -DUKVM_DROP_PRIVILEGES=0 to CFLAGS if dumpcore has been requested. 3. If UKVM_DROP_PRIVILEGES=1, you get the current behaviour in your code. 4. If UKVM_DROP_PRIVILEGES=0, privilege dropping is disabled *AND* ukvm prints a stern warning to this effect at startup, including something about not being recommended for production, etc. Separately from this, and with a view to adding some amount of privilege dropping by default on other systems besides OpenBSD, I think that: 1. The privilege dropping code should be moved into its own top-level function, e.g. ukvm_hv_drop_privileges(), which goes into ukvm_hv_.c. 2. This function is clearly called from ukvm/ukvm_main.c, just before entering the VCPU loop(?). This would also be where the #if printing the warning if disabled (see (4) above) goes. As for what privileges should exactly be dropped on other OSes by default, I need to think about that a bit more and will follow up during the week. However, this should be enough to get you started. Would this approach work for you? Any other opinions? Cheers, -mato
