Re: Web based document / spredsheet editor
On 2020-09-22 15:07, Ottavio Caruso wrote: > On 22/09/2020 14:37, Martin Sukany wrote: >> Hi colleges, >> >> I need to set up some kind of collaborative environment (rich text >> docjuments, basic tables) — request is „something like google docs“. >> >> As I’m almost working in shell I have to say that I’m little bit lost in >> this area. >> >> Could you recommend me some web-based application (idealy something which is >> „easily“ deployed on OpenBSD)? If it wouldn’t have behind some of the ‚big >> frameworks‘, it would be great. > > Whichever web based "like Google docs" solution will require the > latest/greatest version of Chrome/Firefox and probably will work 100% fine > only on Windows/ChromeOS. Firefox and Chromium both work on OpenBSD, too. Demi
Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD
On 2020-09-22 10:58, Theo de Raadt wrote: >> I actually agree with this. Designing a program with pledge in >> mind is always better. However, that requires that the program be >> trusted, and there still may be some corner cases in which I can >> tighten down the pledge more than the program itself can. > > I disagree. I don't believe you can correctly produce security, because > the pledge operation puts the program into an unexpected non-POSIX > operational environment, and will introduce new potential error conditions > the program does not expect. In my use-case, the program’s correct functionality is less important than ensuring that the program cannot break out. >> So I can sandbox ftp(1) more than ftp(1) can reasonably sandbox itself. > > I very strongly disagree. At best the pledge/unveil-wrapper will work in > a specific one-time configuration, and not be generalizable. Indeed it is not generalizable. > We do not want users to be experimenting with things they don't understand, > more precisely, things they cannot understand because this high-level pledge > command is changing big underlying conditions. > >> To be fair, one could argue that ftp(1) should have a command-line >> option that enables these lockdown options and disables the features >> unsupported under this mode. > > Disagree. This is not supposed to be user visible. That’s why I posted the lockdown patch to remove the exec pledge when it isn’t required. >> That isn't actually not the main use case for pledge(1), >> at least for me. The main use-case is to sandbox untrusted, >> potentially malicious executables. > > That is propostrous. > > You think it's a good idea to throw untrusted programs into an > environment they were not designed... Personally, I would prefer to run something like https://play.rust-lang.org under the hardened OpenBSD kernel than under Linux. However, without a way to sandbox these binaries, it can't be done. >> I do not know any way to >> implement something like the Rust Playground securely on OpenBSD >> without using execpromises, at least without requiring at least part >> of the application to run as root. With execpromises, sandboxing >> untrusted executables is trivial. That's what pledge(1) is for. > > No it is not trivial! You are running code in *NON-POSIX MODES*. I know. In my use-case, POSIX conformance is not necessary. Rust works just fine on Windows, for example. >> In my main use-case, I know what pledges I am willing to allow >> untrusted code to have. If it tries to do something that the >> sandbox doesn't allow, it *should* fail. I expect that some >> functionality *will* break. That's okay in my application. > > But you are wrong. There are non-terminating situations in unveil > and pledge, where a program which doesn't test for unexpected error > returns or specific errno's, as this is NOT A CORRECT POSIX ENVIRONEMT, > will go down a wrong path and do the wrong thing. In many cases, these are throwaway programs, often used to share snippets. In others, I would be fine with picking up the pieces myself if things break. What I am NOT fine with is having to run a web application as root, or give it access to doas(1). I am also not wedded to execpromises at all. If there is a better alternative, I would be more than happy to use it. I am just not aware of one. Sincerely, Demi
Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD
On 2020-09-22 09:58, Ingo Schwarze wrote: > Hi Demi, > > Demi M. Obenour wrote on Mon, Sep 21, 2020 at 12:51:34PM -0400: > >> The tool makes essential use of the execpromises argument >> to pledge(2), so that it can sandbox the program it executes. > > This appears to conflict with the basic idea of pledge(2), which > is for the *programmer* to first do simple preparatory work that > requires full syscall access, then pledge(2) according to a precise > understanding of what the program is supposed to do during normal > operation. Usually, it is not possible to properly pledge(2) a > program without designing it for pledge(2), sometimes called > "hoisting". As a corollary, pledging a program from the outside, > without changing the code that is compiled, usually does not > provide significant benefit. I generally agree with you. I do believe that there are a few exceptions, however, as I wrote in my reply to de Raadt. >> While I understand that this argument is slated for removal, >> pledge(1) would not be possible without it. > > Exactly, so this is not likely to go anywhere. > >> pledge(1) is mainly intended for when the program being sandboxed >> is either potentially malicious, > > Even in such cases, pledge(2) needs to be called from *within* > the program. And that is what porters actually do. Two examples > of programs that are very obviously malicious are firefox and > chromium. Still, both call pledge(2) from within. My primary use-case is that I would like to port a Linux web app (the Rust Playground) to OpenBSD. The Rust Playground allows users to supply arbitrary source code, which is then compiled and executed. I have no control over the contents of said code, so I have no way to ensure that these programs will call pledge(2) themselves. Calling pledge(2) externally allows me to sandbox the untrusted binaries. >> If there is interest, I would >> also like to turn pledge(1) into a proper OpenBSD package at some >> point, so that it can be installed using pkg_add(1). > > That might (potentially) meet resistance from porters because > it might stand in the way of deleting the execpromises feature > when the time comes. To be clear, I am only using execpromises because it is the only way I know of to solve my problem under OpenBSD. If there is a better replacement for execpromises, I will happily migrate to using it, but right now, I am not aware of any. Running each untrusted process under a separate user account requires at least part of the web application to run as root, which isn’t desirable. Using execpromises allows the web application to run as an unprivileged user. > Yours, > Ingo Sincerely, Demi
Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD
On 2020-09-22 10:10, Theo de Raadt wrote:
> I gotta comment..
Thank you for your feedback.
>>> The tool makes essential use of the execpromises argument
>>> to pledge(2), so that it can sandbox the program it executes.
>>
>> This appears to conflict with the basic idea of pledge(2), which
>> is for the *programmer* to first do simple preparatory work that
>> requires full syscall access, then pledge(2) according to a precise
>> understanding of what the program is supposed to do during normal
>> operation. Usually, it is not possible to properly pledge(2) a
>> program without designing it for pledge(2), sometimes called
>> "hoisting".
>
> In the simplest cases, pledge removes some support operations, in
> particular relating options hiding under ioctl. More complicated
> pledge use cases follow a "successive drop" feature as program
> initialization starts.
>
> With this kind of pledge-from-parent, the sophisticated cases are
> impossible.
I actually agree with this. Designing a program with pledge in
mind is always better. However, that requires that the program be
trusted, and there still may be some corner cases in which I can
tighten down the pledge more than the program itself can.
For example, ftp(1) must consider all possible places the sysadmin
might put their CA certificates. It also might need to execute
commands as part of interactive mode. However, when using ftp(1)
as part of my modified sysupgrade(8), I know that the CA certificates
will be in the standard location, and that ftp(1) will never need to
exec(2) another program. So I can sandbox ftp(1) more than ftp(1)
can reasonably sandbox itself.
To be fair, one could argue that ftp(1) should have a command-line
option that enables these lockdown options and disables the features
unsupported under this mode. However, that would require that
every single program grow additional options, whereas pledge(1)
is very simple.
> Sadly, almost all programs bigger than "cat" or "more" require a
> huge pledge for initalization, especially if they do accept environment
> variables (themselves or in libc), or use the network. So the pledge
> will always be huge.
>
>> As a corollary, pledging a program from the outside,
>> without changing the code that is compiled, usually does not
>> provide significant benefit.
>
> I agree. I wrote a command like this myself, when I developed the
> execpromises featureset. I am ready to delete exec promises because
> I consider it a failed experiment.
>
> I found that useful application was extremely rare. I could not even
> use execpromises properly in programs like "disklabel -E" to control
> the behaviour of the $EDITOR.
That isn’t actually not the main use case for pledge(1),
at least for me. The main use-case is to sandbox untrusted,
potentially malicious executables. I do not know any way to
implement something like the Rust Playground securely on OpenBSD
without using execpromises, at least without requiring at least part
of the application to run as root. With execpromises, sandboxing
untrusted executables is trivial. That’s what pledge(1) is for.
Much of the benefit of execpromises actually comes from being
able to preserve unveil(2) across execve(2). I am perfectly okay
giving untrusted code "stdio rpath wpath cpath unix proc_exec",
for example, if unveil(2) has prevented it from accessing anything
important on the filesystem. The other benefit of execpromises is
that it reduces the attack surface against the kernel, which makes
sandbox escapes significantly less likely.
> I've been down this road before, and it doesn't work. You can come
> to this conclusion by finding a program, and trying *absolutely everything*
> it does, including environment variables and file openings and such that
> the libraries do. You'll begin with optimism, but eventually add more and
> more pledges.
In my main use-case, I know what pledges I am willing to allow
untrusted code to have. If it tries to do something that the
sandbox doesn’t allow, it *should* fail. I expect that some
functionality *will* break. That’s okay in my application.
> There's one more thing I want to mention: pledge("shitload of options")
> intentionally is a non-POSIX compliant environment. Command line users
> won't understand the edge conditions.
I agree. pledge(1) is meant for advanced users and for those
implementing sandboxes.
Sincerely,
Demi M. Obenour
[ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD
Yesterday, I wrote an unprivileged sandboxing tool for OpenBSD, based
on pledge(2) and unveil(2). I have included the complete C source
code below, and also attached it in case this makes it easier to use.
I called it pledge(1), but am open to suggestions for a better
name. The tool makes essential use of the execpromises argument
to pledge(2), so that it can sandbox the program it executes.
While I understand that this argument is slated for removal,
pledge(1) would not be possible without it.
pledge(1) tries to be smart: it will always unveil the target program
for execution, and will always unveil the dynamic linker and system
library directory for reading. This avoids confusing errors from
execve(2), as well as spurious crashes from the executed program.
pledge(1) is mainly intended for when the program being sandboxed
is either potentially malicious, or doesn’t use pledge(2) and
unveil(2) to the fullest extent possible. For example, ftp(1)
can’t use unveil(2) without significant additional complexity,
as it doesn’t know in advance where the TLS certificates are
located. I often know that in advance, however, so I can apply
tighter sandboxing than ftp(1) can on its own. I can also use
pledge(1) to sandbox untrusted code, for instance in a program like
the Rust Playground (https://play.rust-lang.org) that (by design)
needs to execute arbitrary user-supplied code. While it might
also be possible to achieve this using chroots and routing domains,
using them requires root privileges, whereas pledge(1) works as an
unprivileged user.
There are several potential improvements to be made, but I believe
that the current code is already useful. I use it to sandbox ftp(1)
in a modified version of sysupgrade(8), for example. Bug reports
and feature requests would be greatly appreciated, as would general
suggestions for improving the code. If there is interest, I would
also like to turn pledge(1) into a proper OpenBSD package at some
point, so that it can be installed using pkg_add(1).
The source code is less than 50 lines, so I have included it inline
to make it easier for others to comment on it, if they wish.
---
#include
#include
#include
extern char **environ;
int
main (int argc, char **argv) {
char *end_perms, *arg0 = NULL, *progpath = NULL;
int ch;
while ((ch = getopt(argc, argv, "u:0:")) != -1) {
switch (ch) {
case '0':
if (arg0 != NULL)
errx(3, "arg0 cannot be set twice");
arg0 = optarg;
break;
case 'u':
if ((end_perms = strchr(optarg, ':')) == NULL)
errx(3, "no colon after permissions");
*end_perms = '\0';
if (unveil(end_perms + 1, optarg))
err(2, "unveil");
break;
}
}
if (argc - optind < 2)
errx(3, "not enough arguments");
argc -= optind;
argv += optind;
if (optind < 2 || strcmp(argv[-1], "--") != 0)
errx(3, "no -- before pledge: optind %d", optind);
progpath = argv[1];
if (arg0 != NULL)
argv[1] = arg0;
if (unveil("/usr/libexec/ld.so", "r") ||
unveil("/usr/lib", "r") ||
unveil(argv[1], "x") ||
unveil(NULL, NULL))
err(2, "unveil");
if (pledge(NULL, *argv))
err(2, "pledge");
execve(progpath, argv + 1, environ);
err(1, "execve");
}
---
Sincerely,
Demi M. Obenour
#include
#include
#include
extern char **environ;
int
main (int argc, char **argv) {
char *end_perms, *arg0 = NULL, *progpath = NULL;
int ch;
while ((ch = getopt(argc, argv, "u:0:")) != -1) {
switch (ch) {
case '0':
if (arg0 != NULL)
errx(3, "arg0 cannot be set twice");
arg0 = optarg;
break;
case 'u':
if ((end_perms = strchr(optarg, ':')) == NULL)
errx(3, "no colon after permissions");
*end_perms = '\0';
if (unveil(end_perms + 1, optarg))
err(2, "unveil");
break;
}
}
if (argc - optind < 2)
errx(3, "not enough arguments");
argc -= optind;
argv += optind;
if (optind < 2 || strcmp(argv[-1], "--") != 0)
errx(3, "no -- before pledge: optind %d", optind);
progpath = argv[1];
if (arg0 != NULL)
argv[1] = arg0;
if (unveil("/usr/libexec/ld.so", "r") ||
unveil("/usr/lib", "r") ||
unveil(argv[1], "x") ||
unveil(NULL, NULL))
err(2, "unveil");
if (pledge(NULL, *argv))
err(2, "pledge");
execve(progpath, argv + 1, environ);
err(1, "execve");
}
Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD
On 2020-09-21 12:51, Demi M. Obenour wrote: > Yesterday, I wrote an unprivileged sandboxing tool for OpenBSD, based > on pledge(2) and unveil(2). I have included the complete C source > code below, and also attached it in case this makes it easier to use. I just realized that I forgot to include a license. Consider this code to be released under the same ISC-style license as used by OpenBSD itself. Sincerely, Demi
Re: VMM vulns?
On 2020-09-03 01:09, Mike Larkin wrote: > On Wed, Sep 02, 2020 at 09:36:14PM -0400, Bryan Steele wrote: >> On Wed, Sep 02, 2020 at 02:03:35AM -0700, Mike Larkin wrote: >>> On Wed, Sep 02, 2020 at 03:35:54AM +0200, f...@disciples.com wrote: https://twitter.com/m00nbsd/status/1291257985734410244 I don't want to bump that old thread or start any arguments about this. I'm just curious if this tweet is accurate or have these issues been addressed? Were any of Maxime's suggestions implemented? >>> >>> I am not sure if anyone picked up the remaining issues after I left active >>> vmm development. At that time, I sent out my WIP diff for the TLB flush >>> issue >>> Maxime reported; it was not 100% complete. I am not sure if anyone is >>> working >>> on that or not, or any other issues he reported. >>> >>> -ml >> >> As far as I'm aware all the pvclock(4) issues were addressed by pd@ and >> mortimer@. >> >> https://marc.info/?l=openbsd-cvs=158180761313544=2 >> https://marc.info/?l=openbsd-cvs=158269876318391=2 >> >> The "assorted bugs and vulns" like the RDMSR passthrough and the XSETBV >> CPL check issues were handled by pd@, me and kettenis@ and they have all >> been committed. >> >> https://marc.info/?l=openbsd-cvs=158196338821895=2 >> >> The direct map issue on Intel CPUs hinted at by Maxime was also fixed >> by kettenis@, deraadt@ and millert@. >> >> https://marc.info/?l=openbsd-cvs=158269724517998=2 >> >> -Bryan. >> > > The TLB flush issues are still outstanding. > > -ml Yikes! Is https://openbsd.amsterdam affected? -Demi signature.asc Description: OpenPGP digital signature
Assigning the same IP address to multiple interfaces
How do I assign the same IP and MAC address to multiple interfaces? This is easy on Linux, but I cannot figure out how to do it on OpenBSD. The (virtual) machine is assigned a single IP address by the hypervisor, so changing the IP not an option, and bridging is a no-go as all the peers share a MAC address. All netmasks are /32 for IPv4 and /128 for IPv6. Each of the interfaces is a point-to-point Ethernet link, and both its IP and MAC address and that of its peer are statically known. All routes are also assigned statically. In short, I need to assign a route based purely on the name of an interface. The -ifp keyword in route(8) seems like it should be used for this, and the kernel sources indicate that it can be used to disambiguate which interface should be selected. However, I was not able to get it to work. I don’t have access to the VM I was using for testing anymore, but if I recall correctly, the C code and shell scripts I was using did the equivalent of the following: # ifconfig xnf0 inet 10.137.0.77 prefixlen 32 # route -n delete 10.137.0.77/32 10.137.0.77 # # this doesn’t work due to a route(8) bug ― I was using C code instead # # I submitted a bug report (with patch) to bugs@ a while back # route -n add -inet 10.137.255.254 -link fe:ff:ff:ff:ff:ff -ifp xnf0 -ifa 10.137.0.77 # ifconfig vether0 create lladdr fe:ff:ff:ff:ff:ff # ifconfig vether0 inet 10.137.0.77 prefixlen 32 # # this doesn’t work due to a route(8) bug ― I was using C code instead # route -n add -inet 10.139.255.254 -link fe:ff:ff:ff:ff:ff -ifp vether0 -ifa 10.137.0.77 # route -n delete 10.137.0.77/32 10.137.0.77 $ route -n show I expect that the route would to 10.139.255.254 would go through vether0, but it goes through xnf0 instead. If I then run: # ifconfig xnf0 -inet $ route -n show the route is gone. Should the above commands have worked? If not, is this just unsupported in OpenBSD? If it is supported, what should I have done differently? I did manage to create a workaround: I can assign each interface a unique alias address from the 169.254.0.0/16 link-local range, and use PF to NAT packets in this range to 10.137.0.77. However, this feels like an ugly hack. For IPv6, I can use the link-local address of each interface as the -ifa argument, so I am much less worried. Thank you for your time and attention. Sincerely, Demi M. Obenour signature.asc Description: OpenPGP digital signature
Re: static IPv6 setup is not working stable
On 2020-08-06 09:51, Janne Johansson wrote: > I have a setup where the virtualization (KVM) combined with the networking > does present a IPv6 def-gw as both an fe80:: and > the more normal 2001:a:b:c:d::1/64 and where the 2001-v6 ip works far > better on virtual machines due to redundancy mac sync things on the network > side, and since the ndp list showed the fe80::1 had a VRRP/CARP-lookalike > mac, it could be the same. > > In my case both bsd and linux IPv6-using VMs suffer from ndp "drops" where > it can take seconds for the discovery to figure the mac address out again > after a drop. > > So if you can divine what the "real" v6 ip is of the default-gw, try > setting this hard in the conf or /etc/mygate and retry v6. > > > Den tors 6 aug. 2020 kl 14:46 skrev Matthias Schmidt : > >> Hi, >> >> * kug1977 wrote: >>> >>> Is this something wrong configured on OpenBSD server or is this something >>> the provider has to check on the gateway side? >> >> I also have a VM at the exact same provider (netcup) and face >> the same problem. Since all of my VMs at different providers are >> identical (base install + conf via ansible) and I don't see the issue at >> other providers (IONOS, Hetzner) I suspect it has nothing to do with >> OpenBSD... The best option I know of is to add a static, permanent NDP entry with ndp(8) entry before bringing up the interface. This works even if the peer does not respond to NDP at all. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: Installation in a Xen guest (pvgrub)
On 2020-07-24 14:36, Markus Kolb wrote: > Am 24.07.2020 17:30, schrieb Theo de Raadt: > [...] >> non-OpenBSD bootloaders will do a shitty job of booting OpenBSD. >> I'm not going to bother explaining the situation in detail. People >> who try to go that way have already decided they don't care about the >> consequences. > > Ok. Thanks. > > Are you talking about biosboot or 2nd stage boot? > > But would it be in theory possible to program a > (1) specialized "bootloader" which is bootable by linux-cmd of grub > and > (2) this specialized "bootloader" continues with the BSD boot code? At the > moment I'm thinking of 2nd stage boot. > So going from grub 2nd stage via fake-linux-kernel to 2nd stage OpenBSD > boot... > > Part 1 should be doable. > But what is about part 2? Would it be possible or are there technical system > restrictions making it impossible e.g. like CPU operating modes or > restrictions to access the BIOS? > And so any further thinking and investigation in this way is waste of time... I highly doubt OpenBSD will work in PVH mode without both kernel and bootloader changes. This isn’t specific to OpenBSD, btw. Windows has the same restriction. The primary reason is that PVH mode doesn’t expose any emulated hard drives. Unless boot(8) has support for Xen PV block devices, this will prevent it from loading the kernel. Is there some reason you cannot use HVM? OpenBSD on Xen works well in HVM mode. OpenBSD lacks PV console support, so you will need to rely on emulated serial and/or VGA, but you do get PV netfront and blockfront drivers. That said, don’t expect tight integration with the host system. There are no userspace APIs for Xen hypercalls, for instance, so vchans won’t work. On the other hand, if you don’t need any advanced Xen-specific features, OpenBSD will work fine. PCI passthrough works too. XenStore can be accessed via hostctl(8). Are you trying to make OpenBSD work on QubesOS? If so, I have an OpenBSD TemplateVM that works somewhat well, although qrexec and qubesd don’t work due to the aforementioned lack of vchans. If not, would you mind going into detail about your host configuration? I suspect that the closer the virtual environment is to bare hardware, the better OpenBSD will behave. The host will also need to provide a DHCP server if you want network autoconfiguration to work. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: how to pledge(2) for Yubikey
On 2020-07-14 12:58, Stuart Henderson wrote: > Known problem, there's no nice way around it though. The standard model > used on most OS of controlling many simpler USB devices from a low > privileged userland process does not work too well with the approach > in https://cvsweb.openbsd.org/src/etc/MAKEDEV.common#rev1.105 > > afaik the options for this are chmod, run as root, or write a driver that > works similar to fido(4) and modify the existing software that interfaces > with the device to use that instead (I guess for yk it will need a way to > hook into the keyboard driver too for the usual button-press keyboard > emulation otp mode). One approach is to grant access to the user logged in at the console. Another approach is to write a userspace daemon that has permission to interact with the device, and which can handle access control itself. I prefer this approach, as it reduces the kernel’s attack surface. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: Potential grep bug?
On 2020-06-23 22:29, Jordan Geoghegan wrote:
> Hello,
>
> I was working on a couple POSIX regular expressions to search for and
> validate IPv4 and IPv6 addresses with optional CIDR blocks, and encountered
> some strange behaviour from the base system grep.
>
> I wanted to validate my regex against a list of every valid IPv4 address, so
> I generated a list with a zsh 1 liner:
>
> for i in {0..255}; do; echo $i.{0..255}.{0..255}.{0..255} ; done | tr
> '[:space:]' '\n' > IPv4.txt
>
> My intentions were to test the regex by running it with 'grep -c' to confirm
> there was indeed 2^32 addresses matched, and I also wanted to benchmark and
> compare performance between BSD grep, GNU grep and ripgrep. The command I
> used:
>
> grep -Eoc
> "((25[0-5]|(2[0-4]|1{0,1}[[:digit:]]){0,1}[[:digit:]])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[[:digit:]]){0,1}[[:digit:]])(/[1-9]|/[1-2][[:digit:]]|/3[0-2])?"
>
> My findings were surprising. Both GNU grep and ripgrep were able get through
> the file in roughly 10 and 20 minutes respectively, whereas the base system
> grep took over 20 hours! What interested me the most was that the base system
> grep when run with '-c' returned '0' for match count. It seems that 'grep -c'
> will have its counter overflow if there are more than 2^32-1 matches
> (4294967295) and then the counter will start counting from zero again for
> further matches.
Does OpenBSD use an NFA/DFA regular expression implementation, or a
backtracking one? If it uses the latter, then your regex is probably
causing catastrophic backtracking.
> Regards,
>
> Jordan
Sincerely,
Demi
signature.asc
Description: OpenPGP digital signature
Re: Installation in a Xen guest (pvgrub)
On 2020-07-09 05:06, Markus Kolb wrote: > Hi, > > is there a possibility to install/boot OpenBSD in a Xen guest which is booted > by pvgrub1 or pvgrub2? The pvgrub is configured to use a /boot/grub/grub.cfg > of the guest in the 1st partition. > > In a non-Xen-grub there is a bsd-module which can boot the installer bsd.rd, > but this bsd-module is not available in the xenhost-builds of grub. > There is also no chain-module for chainloader configs. > > Any ideas? > > Thanks > Markus For me, OpenBSD boots fine in HVM mode (with an I/O emulator). I have not tried PVH mode and would not expect it to work. PV mode definitely won’t work, and should be avoided anyway for both security and performance reasons. Is HVM mode okay, or do you need PVH? Sincerely, Demi
Re: Setting permanent neighbor entry
On 2020-05-26 09:34, Kanto Andria wrote: > Hello, > man ndp is probably another solution > > On Tuesday, May 26, 2020, 9:17:25 a.m. EDT, Tommy Nevtelen > wrote: > > On 26/05/2020 11.38, Demi M. Obenour wrote: >> What is the OpenBSD equivalent to this Linux command? >> >> ip neighbor add 2001:db8::1 dev xnf0 lladdr fe:ff:ff:ff:ff:ff router nud >> permanent >> >> It doesn’t need to be a single command. If the existing userspace >> tooling does not support this, is it possible to do it via the >> kernel APIs? > man arp I already tried this, but it does not work if there is already an entry. Removing it and re-adding it is racy: a new entry might appear before I can override it. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Setting permanent neighbor entry
What is the OpenBSD equivalent to this Linux command? ip neighbor add 2001:db8::1 dev xnf0 lladdr fe:ff:ff:ff:ff:ff router nud permanent It doesn’t need to be a single command. If the existing userspace tooling does not support this, is it possible to do it via the kernel APIs? Sincerely, Demi signature.asc Description: OpenPGP digital signature
Sending IPv6 packets via an interface even when NDP is not available
How can I force all IPv6 packets sent via a certain route to: - Be directed out of a certain interface - Sent to a certain MAC address - Regardless of whether NDP works? I don’t know the peer’s IPv6 address, but I do know the interface and MAC address. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Managing multiple OpenBSD systems with a single base install
I am working on an OpenBSD-based QubesOS TemplateVM, and have run into a few problems. In QubesOS, all volumes of a TemplateVM are persistent. AppVMs based on a TemplateVM use a (copy of) the TemplateVM’s root partition, but have their own private partition, which is set to zero when the VM first boots up. Finally, DispVMs have no persistent storage at all. This leads to a few difficulties. First, I found that I need to mount various directories from the persistent volume (which I mounted at /mnt/rw) over the root volumes (mounted at / and /usr in my case). Linux AppVMs use bind mounts for that purpose, but OpenBSD doesn’t have bind mounts, so I use NFS over loopback. Since that is slow, I symlinked /home to /mnt/rw/home. Furthermore, when an AppVM first starts up, /mnt/rw will not be mountable, as the underlying storage will consist entirely of zeroes. I wrote a C program that uses disklabel(5) ioctls to handle this. However, this breaks sysupgrade(8), since /home is symlinked to /mnt/rw/home, which doesn’t exist until /etc/rc.securelevel runs. I fixed this by monkeypatching sysupgrade(8) to download into /var/_sysupgrade instead, but that is an ugly hack. The other problem is that I do not know of a reliable way to make the boot process fail if my /etc/rc.securelevel fails. This is security-critical, as it does tasks like deleting SSH keys from /etc/ssh so that they will be regenerated after /mnt/rw/export/etc/ssh has been mounted over /etc/ssh. If this fails, there is a chance that two AppVMs could share the same SSH host keys, which would be bad. Furthermore, if mounting /mnt/rw fails, I would much prefer to drop into a single-user shell than to try to continue. This is a trivial patch to /etc/rc, but patching /etc/rc is strongly discouraged in afterboot(8). Are the solutions I came up with the best possible, or are there better ones that I missed? Any help will be greatly appreciated. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: Including AnonCVS mirrors in ssh_known_hosts
On 2019-12-09 10:41, Theo de Raadt wrote: > > the project doesn't run the anoncvs servers. we are not able > to provide you with a list which has more validity than your own > checks. > I (mistakenly) considered the list on the OpenBSD website to be official. Sorry. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: Including AnonCVS mirrors in ssh_known_hosts
On 2019-12-09 10:33, Theo de Raadt wrote: > Demi M. Obenour wrote: > >> Would it be possible to include the default AnonCVS mirrors’ SSH >> fingerprints in the default ssh_known_hosts? > > There is no default ssh_known_hosts file. > >> If not, could it be included in another file in the base system? > > And teach users to trust us, rather than following best practice > of doing signature checks? No way. I would be more than happy to do signature checks. The problem is that I have no idea where I can find a signed list of those fingerprints, or another way of verifying them. That’s why I asked! If OpenBSD used GPG-signed Git commits or similar, I could verify that, but it does not. That isn’t meant as a criticism, BTW. It just means that if I want to follow the -current source repository, I need some way to verify the authenticity of the source code. If there is something wrong with my reasoning, I would love to know. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Including AnonCVS mirrors in ssh_known_hosts
Would it be possible to include the default AnonCVS mirrors’ SSH fingerprints in the default ssh_known_hosts? If not, could it be included in another file in the base system? Sincerely, Demi signature.asc Description: OpenPGP digital signature
Cannot configure IPv6 to a neighbor that drops NDP traffic
I am trying to configure IPv6 support for an OpenBSD VM running on QubesOS, but have not been successful. Is this likely due to NDP traffic being blocked by the peer? If so, is there a workaround? Linux manages to connect fine. For context, QubesOS uses Xen networking, and drops all IP traffic that is not directly from a VM’s assigned address. This includes traffic on link-local addresses. Thank you, Demi
