Re: Solid-Run's HoneyComb LX2K for OpenBSD
> How good are the chances of the 'HoneyComb LX2K' running OpenBSD? [1] > > Footnotes: > [1] https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/ For future reference, the more specific place to ask is a...@openbsd.org and the places to see before asking are: https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/INSTALL.arm64 https://ftp.openbsd.org/pub/OpenBSD/6.6/arm64/INSTALL.arm64 https://www.openbsd.org/arm64.html For now, the LX2K looks less likely to run OpenBSD than any of the documented targets of OpenBSD/arm64, there is one offering from SolidRun which is a good sign: Allwinner A64/H5 Pine64 Pine 64/64+ NanoPi A64 Orange Pi PC2 AMD Opteron A1100 (Seattle) AMD Seattle Development Board SoftIron OverDrive 1000 SoftIron OverDrive 3000 Amlogic G12A/B Hardkernel ODROID-N2 Ampere eMAG Lenovo ThinkSystem HR330A Lenovo ThinkSystem HR350A Broadcom BCM2837 Raspberry Pi 3 Marvell ARMADA 7K/8K SolidRun/Marvell MACCHIATObin[1] Rockchip RK3328/RK3399 Pine64 ROCK64 Pine64 ROCKPro64 Firefly-RK3399 Theobroma Systems RK3399-Q7 Socionext SC2A11 Socionext SynQuacer-E Developerbox Footnotes: [1] https://www.solid-run.com/marvell-armada-family/macchiatobin/ -- VanL.
Re: password-less user (without bothering security(8))?
Le mar. 10 déc. 2019 à 16:52, Adam Thompson a écrit : > > Is there a way to placate security(8) that I'm just not seeing? Or is > my goal fundamentally misguided for some reason I'm not seeing? The > user in this case is semi-trusted (e.g. yes, we'll let you login using > an unprivileged account to run bgpctl in pipelines) but not > organizationally-trusted (i.e. but that's ALL we want you to do on this > system). If bgpctl is the only thing you want, have a look at bgplgsh(8). It doesn't do everything bgpctl does (only show/ping/traceroute), but it might be sufficient for your needs.
Re: Strong Host Model in OpenBSD network stack
Good evening all,
following up on the previous discussions, I noticed that the network
stack changed recently [1] (limited to cases when packet forwarding is
enabled).
What's the idea behind it, as it seemed to be unlikely that this default
would be changed at all?
Thanks,
Bastian
[1] https://marc.info/?l=openbsd-tech&m=157580561114203
Am 18.10.19 um 08:56 schrieb Claudio Jeker:
> On Thu, Oct 17, 2019 at 09:50:28PM +0200, Bastian Kanbach wrote:
>> Hello,
>>
>> recently I was performing some checks that relate to the "Strong Host
>> Model" and "Weak Host Model", and I noticed that OpenBSD was behaving
>> different than I expected. I always assumed that the network stack of
>> OpenBSD was following the "Strong Host Model", but I might be wrong with
>> that:
> OpenBSD does follow the "Weak Host Model". Has always been like that.
>
>> Basically the Strong Host Model means that the network stack "accepts
>> locally destined packets if the destination IP address in the packet
>> matches an IP address assigned to the network interface on which the
>> packet was received."
>>
>> FreeBSD and NetBSD have a sysctl property for this, called
>> "net.inet.ip.check_interface", which defaults to 0 (Weak Host Model).
>> However for OpenBSD I haven't seen such a property at all.
>>
>>
>> Basically my setup consisted of the following virtual machines and
>> network interfaces (IP-Forwarding disabled):
>>
>>
>> VM 1 (OpenBSD 6.5):
>>
>> em0: 192.168.100.1/24 ("Internal Network")
>>
>> em1: 10.0.0.97/24 ("NAT")
>>
>>
>> VM 2 (Ubuntu Server 18.10):
>>
>> ens33: 192.168.100.2/24 ("Internal Network")
>>
>>
>>
>>
>>
>> As expected, ens33 of VM2 can communicate with em0 of VM1, since both
>> interfaces are associated with the same Virtualbox network, and both IP
>> addresses are part of the same /24 subnet.
>>
>> ens33 of VM2 can't directly communicate with em1 of VM1, since the IP
>> addresses are part of different subnets and no routes were configured.
>>
>>
>> Then I performed 2 tests:
>>
>>
>> Test 1:
>>
>> Perform an arping from ens33/VM2 (192.168.100.2) to 10.0.0.97 (VM1). The
>> packet was NOT answered by VM1.
>>
> This is a Layer 2 ARP test. Since 10.0.0.97 is not on that interface arp
> will not answer. The host model only matters for Layer 3.
>
>> Test 2:
>>
>> Set the following route on VM2: ip r add 10.0.0.0/24 via 192.168.100.1.
>> Then send an ICMP echo request to 10.0.0.97 (VM1), originating from
>> 192.168.100.2 (VM2). VM1 replied with an ICMP echo reply (with a source
>> MAC address of interface em0).
>>
>>
>> While the behaviour of Test 1 indicates that the Strong Host Model is
>> followed, Test 2 shows the behaviour of a "Weak Host Model".
>
> No, Test 1 is not the right test for the host model.
>
>> What of both is actually supposed to be the default for OpenBSD? Is
>> there any kernel parameter to control these behaviours, like
>> net.inet.ip.check_interface for FreeBSD or NetBSD?
> We don't have a button and just follow the "Weak Host Model".
> You can enforce a strong model per interface with pf(4):
>
> block in on !em0 inet to (em0)
>
> or
>
> block in
> pass in on em0 to (em0)
> pass in on em1 to (em1)
>
Re: password-less user (without bothering security(8))?
Evan Silberman writes: > Why not assign a long, random password and then not share it with the > user? Or you can set your encrypted password to "*" as it is done for other daemon users. You can use chpass(1) for this. -- Manuel Giraud
Re: password-less user (without bothering security(8))?
Am 10.12.2019 17:07 schrieb Evan Silberman: Is there a way to placate security(8) that I'm just not seeing? Or is my goal fundamentally misguided for some reason I'm not seeing? The user in this case is semi-trusted (e.g. yes, we'll let you login using an unprivileged account to run bgpctl in pipelines) but not organizationally-trusted (i.e. but that's ALL we want you to do on this system). Why not assign a long, random password and then not share it with the user? Or put 13 asterisks as "password" in master.passwd(5) (the case is mentioned explicitly there) HTH, -- pb
Re: password-less user (without bothering security(8))?
> On Dec 10, 2019, at 7:55 AM, Adam Thompson wrote: > > Hi, > On 6.6-STABLE, I'm looking at security(8) and it's not immediately obvious to > me how I can have an SSH key-only user who does not have a password, that > also does not trigger daily security warnings. > > The goal is to have a user that can never log in on the console, or via > password any other way (FTP, SMTP auth, POP, etc., etc.), but only via the > RSA key provided. > > Is there a way to placate security(8) that I'm just not seeing? Or is my > goal fundamentally misguided for some reason I'm not seeing? The user in > this case is semi-trusted (e.g. yes, we'll let you login using an > unprivileged account to run bgpctl in pipelines) but not > organizationally-trusted (i.e. but that's ALL we want you to do on this > system). Why not assign a long, random password and then not share it with the user?
password-less user (without bothering security(8))?
Hi, On 6.6-STABLE, I'm looking at security(8) and it's not immediately obvious to me how I can have an SSH key-only user who does not have a password, that also does not trigger daily security warnings. The goal is to have a user that can never log in on the console, or via password any other way (FTP, SMTP auth, POP, etc., etc.), but only via the RSA key provided. Is there a way to placate security(8) that I'm just not seeing? Or is my goal fundamentally misguided for some reason I'm not seeing? The user in this case is semi-trusted (e.g. yes, we'll let you login using an unprivileged account to run bgpctl in pipelines) but not organizationally-trusted (i.e. but that's ALL we want you to do on this system). Thanks, -Adam
Re: What's up with bluhms perf tests?
On 10/12/2019 01.12, Todd C. Miller wrote: That was probably the following commit: https://www.mail-archive.com/source-changes@openbsd.org/msg111985.html which has since been reverted: https://www.mail-archive.com/source-changes@openbsd.org/msg112279.html Great! Thanks for the info, hope it shows up in the next run. I'm following it for eventual performance increases for router usage. Kind of hoping for some soon otherwise openbsd might have to go in our networks ); /T
Re: pinentry-tty in OpenBSD? to be used with emacs
Timo Myyrä writes: > I don't know about pinentry but emacs freezes sound familiar. Have you > tried using the workaround given in following site: > https://omecha.info/blog/org-capture-freezes-emacs.html > > Timo Thanks! The freezing using a graphical emacs made me change to a terminal emacs. The link seems relevant to me (I first tried to move to the athena build [also because with GTK build there is some long lasting bug when one runs emacs in its daemon mode], but no matter what, emacs froze randomly at the very point the linked page discusses. So I will try the quick fix (a hack, I would say); still, he only changes an x-selection-timeout from 5000 ms to 10 ms, while my emacs froze (when it did) apparently forever (ie, not just for 5 s). Regarding the pinentry-emacs I now have yet another problem. When the pinentry prompt appears in one emacs frame (on one computer, say at work), as it happens for me when the validity of the passphrase has timed out, it blocks any other emacs frame. Ie, when I run emacsclient -c from another machine, it freezes. I tried a few things to no avail... Thanks for any help. Best regards Ruda
