Re: Support for ath10k QCA988x devices
On 2020-01-28, Alexander Merritt wrote: > Hello, > > I am curious if there is any info on support for the wireless chipset > Qualcomm Atheros QCA988x in the ath10k drivers. These devices are sold by > PCEngines. Prior discussions I found on this list: > > On 2014-04-17 Thom Lauret wrote >> 802.11n is not yet supported in OpenBSD. This is outdated. > On 2015-09-23 Stuart Henderson wrote >> > http://www.pcengines.ch/wle600vx.htm >> >> This is a QCA9882 from the 802.11ac range, on Linux this uses the >> Ath10k driver. Not yet supported on OpenBSD. > > On 2017-04-12 Stefan Sperling wrote >> ath10k devices are not supported. They need a new driver because Atheros >> has changed the driver<->hardware interface with this generation of devices. These two are still valid. > Is there any update? A brief look in the source code and manual did not show > anything. > > What effort is required to implement a new driver, as Stefan mentions? Port > something from another BSD? From Linux? Start from scratch? > > My motivation is to build a wireless router supporting 802.11ac (with OpenBSD > if possible). Compex WLE600VX and WLE900VX support 867Mbps and 1300Mbps, > respectively, according to their data sheets. > > I am not bound to this chipset, if there are alternatives which do work. At a minimum, porting the driver from another OS, but AFAIK (I may be wrong) there will need to be wider changes to the net80211 stack before other 11ac devices will work. (fewer changes were needed for bwfm where a lot more of the stack is run on the NIC itself).
Re: bridge with unexpected ping forwarding
On 2020-01-31, PJ wrote: > I have a router-to-be with 4 NICs, on which ip-forwarding is not yet > enabled (and with OpenBSD 6.6). > > One IF has an IP on one network segment and the three other IFs are > bridged together, with one of the three having an IP on another network > segment. > > When I pinged the first IF, which should be alone on it's network > segment, from a machine connected to one of the three bridged together > IFs, I got a ping reply. I didn't expect it because forwarding is not > enabled. > > What's going on here? > > Am I missing something? It isn't forwarding, it's answering locally. However this changed recently in -current: https://marc.info/?l=openbsd-cvs=157580332113635=2 https://en.wikipedia.org/wiki/Host_model
Re: Recovering corrupted encrypted partition
On Jan 31 18:25:45, int1...@airmail.cc wrote: > Hello, > Recently my 6.6-stable machine lost power while on, which aparently > corrupted a softraid crypto partition (not a boot partition) that was > mounted. Trying to decrypt it with the same bioctl command i usually > use fails with the error: > softraid0: invalid metadata format What bioctl command is that? > After searching all over the mailing list archives, I couldn't find a > solution that didn't destroy data. Some people suggested zeroing the > first megabyte and reconfiguring the disklabel, but I'm not sure if that > would overwrite my existing data. Recreate the softraid crypto partition and restore the data from backups.
Re: FreeBSD daemon(8)-like command for OpenBSD
On Fri, Jan 31, 2020 at 06:39:04PM +, Moisés Simón wrote:
> Sorry to hijack,
>
> Do you know of any basic guide for this?
>
> I have done a syslog normalizer daemon which calls pledge(), unveil() and
> redirects std{out,err} and forks to search and normalize the logs.
>
> I'm not professional programmer so I'm doing my best and want to learn as
> much as I can.
>
> Thank you
I guess the best guide is the code itself :) You can have a look at
/usr/src/lib/libc/gen/daemon.c, where the libc function daemon(3) is
defined. You can also see a simple and complete example in the code of
something like tftpd at /usr/src/usr.sbin/tftpd/tftpd.c
that code uses a local clone of daemon(3) (that is called rdaemon),
but the logic is exactly the same, and it's a full working example
with chdir(2) (or chroot(2)), privilege drop, fork(2), setsid(2),
close stdin/stdout/stderr, and pledge(2) before the daemon starts to
do its things.
Ingo has already provided pointers to excellent resources about the
general concepts and the typical organisation and implementation of
processes in Unix.
HTH
Re: Resource temporarily unavailable: have to recompile?
Cancel the cancellation. I am still seeing this problem, even after logging out/in and ulimit -u shows 712. Running "ps -U myusername|less" yields about 180 lines and the system becomes unable to start even another xterm, or in tmux on a console, unable to start another shell window (in both cases: "Resource temporarily unavailable"). On 01-31 13:20, Luke A. Call wrote: > Hi misc. > > Am I running into a limit that will require recompiling the kernel > (or changing my work style I suppose)? Which man pages should I read > next, or should I be thinking about this differently? > > I am getting "Resource temporarily unavailable" in > /var/log/authlog when I try to open too many "ssh [-X] user@localhost" > connections, or even "fork: retry: Resource temporarily unavailable" when > running "$ cat > /tmp/somefile". > > In "man 3 __tfork" I see: > [EAGAIN]Resource temporarily unavailable. The system-imposed > limit on the total number of threads under execution > would be exceeded. This limit is configuration- > dependent. > > [EAGAIN]Resource temporarily unavailable. The system-imposed > limit MAXUPRC on the total number of threads under > execution by a single user would be exceeded. MAXUPRC > is currently defined in as CHILD_MAX, > which is currently defined as 80 in . > > (If multiple users could simultaneously run X, I might not ssh as much; > suggestions welcome there also, if you are in the mood.) > > > More details, not sure if needed: > > When I open a large # of xterms which make ssh -X connections on > my laptop with obsd 6.5 (planning to upgrade, haven't quite yet), they at > first pause saying > -bash: fork: retry: Resource temporarily unavailable > ...then start failing with > shell request failed on channel 0 > ...and in /var/log/authlog I see: > sshd[52954]: error: do_exec_pty: fork: Resource temporarily unavailable > > Also, until recently I would get error messages in ~/.xsession-errors like: > xterm: Error 32, errno 6: Device not configured Reason: > get_pty: not enough ptys > ...but, after creating more ptys by running (as root) > cd /dev; sh MAKEDEV pty1 #then, um, with pty2, pty3, 4, and 5 > > ...I don't seem to get the "not enough ptys" anymore, and can open > all the xters I like, but I get the > above "xterm: Error 32, errno 6: Device not configured Reason: > get_pty: not enough ptys" from authlog, and the "shell request failed > on channel 0" from the ssh client, all even when I do this not under X. > > It's like I can't get beyond about 20-23 "ssh user@localhost" connections > (depending on how they are counted). > > I have expanded limits in /etc/login.conf and kern.maxfiles=3500 now, in > sysctl.conf, but that is just poking in the dark. > > What am I missing? Thanks! > -Luke > > dmesg: > ached > uhidev4 detached > uhid5 detached > uhid6 detached > uhid7 detached > uhid8 detached > uhidev5 detached > uhidev3 at uhub5 port 3 configuration 1 interface 0 "Logitech USB Receiver" > rev 2.00/12.07 addr 3 > uhidev3: iclass 3/1 > ukbd1 at uhidev3: 8 variable keys, 6 key codes > wskbd2 at ukbd1 mux 1 > wskbd2: connecting to wsdisplay0 > uhidev4 at uhub5 port 3 configuration 1 interface 1 "Logitech USB Receiver" > rev 2.00/12.07 addr 3 > uhidev4: iclass 3/1, 8 report ids > ums1 at uhidev4 reportid 2: 16 buttons, Z and W dir > wsmouse1 at ums1 mux 0 > uhid2 at uhidev4 reportid 3: input=4, output=0, feature=0 > uhid3 at uhidev4 reportid 4: input=1, output=0, feature=0 > uhid4 at uhidev4 reportid 8: input=1, output=0, feature=0 > uhidev5 at uhub5 port 3 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/12.07 addr 3 > uhidev5: iclass 3/0, 33 report ids > uhid5 at uhidev5 reportid 16: input=6, output=6, feature=0 > uhid6 at uhidev5 reportid 17: input=19, output=19, feature=0 > uhid7 at uhidev5 reportid 32: input=14, output=14, feature=0 > uhid8 at uhidev5 reportid 33: input=31, output=31, feature=0 > uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB > OPTICAL MOUSE" rev 1.10/1.00 addr 3 > uhidev6: iclass 3/1, 1 report id > ums2 at uhidev6 reportid 1: 3 buttons, Z dir > wsmouse2 at ums2 mux 0 > wsmouse2 detached > ums2 detached > uhidev6 detached > uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB > OPTICAL MOUSE" rev 1.10/1.00 addr 3 > uhidev6: iclass 3/1, 1 report id > ums2 at uhidev6 reportid 1: 3 buttons, Z dir > wsmouse2 at ums2 mux 0 > wsmouse2 detached > ums2 detached > uhidev6 detached > uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB > OPTICAL MOUSE" rev 1.10/1.00 addr 3 > uhidev6: iclass 3/1, 1 report id > ums2 at uhidev6 reportid 1: 3 buttons, Z dir > wsmouse2 at ums2 mux 0 > wsmouse2 detached > ums2 detached > uhidev6 detached > uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB > OPTICAL MOUSE" rev 1.10/1.00 addr 3 >
Re: Resource temporarily unavailable: have to recompile?
Sorry. It seems to have been just a ulimit and a login.conf value that I had not increased enough. On 01-31 13:20, Luke A. Call wrote: > [] > I am getting "Resource temporarily unavailable" in > /var/log/authlog when I try to open too many "ssh [-X] user@localhost" > connections, or even "fork: retry: Resource temporarily unavailable" when > running "$ cat > /tmp/somefile". > > In "man 3 __tfork" I see: > [EAGAIN]Resource temporarily unavailable. The system-imposed > limit on the total number of threads under execution > would be exceeded. This limit is configuration- > dependent. > > [EAGAIN]Resource temporarily unavailable. The system-imposed > limit MAXUPRC on the total number of threads under > execution by a single user would be exceeded. MAXUPRC > is currently defined in as CHILD_MAX, > which is currently defined as 80 in .
bridge with unexpected ping forwarding
I have a router-to-be with 4 NICs, on which ip-forwarding is not yet enabled (and with OpenBSD 6.6). One IF has an IP on one network segment and the three other IFs are bridged together, with one of the three having an IP on another network segment. When I pinged the first IF, which should be alone on it's network segment, from a machine connected to one of the three bridged together IFs, I got a ping reply. I didn't expect it because forwarding is not enabled. What's going on here? Am I missing something?
Resource temporarily unavailable: have to recompile?
Hi misc. Am I running into a limit that will require recompiling the kernel (or changing my work style I suppose)? Which man pages should I read next, or should I be thinking about this differently? I am getting "Resource temporarily unavailable" in /var/log/authlog when I try to open too many "ssh [-X] user@localhost" connections, or even "fork: retry: Resource temporarily unavailable" when running "$ cat > /tmp/somefile". In "man 3 __tfork" I see: [EAGAIN]Resource temporarily unavailable. The system-imposed limit on the total number of threads under execution would be exceeded. This limit is configuration- dependent. [EAGAIN]Resource temporarily unavailable. The system-imposed limit MAXUPRC on the total number of threads under execution by a single user would be exceeded. MAXUPRC is currently defined in as CHILD_MAX, which is currently defined as 80 in . (If multiple users could simultaneously run X, I might not ssh as much; suggestions welcome there also, if you are in the mood.) More details, not sure if needed: When I open a large # of xterms which make ssh -X connections on my laptop with obsd 6.5 (planning to upgrade, haven't quite yet), they at first pause saying -bash: fork: retry: Resource temporarily unavailable ...then start failing with shell request failed on channel 0 ...and in /var/log/authlog I see: sshd[52954]: error: do_exec_pty: fork: Resource temporarily unavailable Also, until recently I would get error messages in ~/.xsession-errors like: xterm: Error 32, errno 6: Device not configured Reason: get_pty: not enough ptys ...but, after creating more ptys by running (as root) cd /dev; sh MAKEDEV pty1 #then, um, with pty2, pty3, 4, and 5 ...I don't seem to get the "not enough ptys" anymore, and can open all the xters I like, but I get the above "xterm: Error 32, errno 6: Device not configured Reason: get_pty: not enough ptys" from authlog, and the "shell request failed on channel 0" from the ssh client, all even when I do this not under X. It's like I can't get beyond about 20-23 "ssh user@localhost" connections (depending on how they are counted). I have expanded limits in /etc/login.conf and kern.maxfiles=3500 now, in sysctl.conf, but that is just poking in the dark. What am I missing? Thanks! -Luke dmesg: ached uhidev4 detached uhid5 detached uhid6 detached uhid7 detached uhid8 detached uhidev5 detached uhidev3 at uhub5 port 3 configuration 1 interface 0 "Logitech USB Receiver" rev 2.00/12.07 addr 3 uhidev3: iclass 3/1 ukbd1 at uhidev3: 8 variable keys, 6 key codes wskbd2 at ukbd1 mux 1 wskbd2: connecting to wsdisplay0 uhidev4 at uhub5 port 3 configuration 1 interface 1 "Logitech USB Receiver" rev 2.00/12.07 addr 3 uhidev4: iclass 3/1, 8 report ids ums1 at uhidev4 reportid 2: 16 buttons, Z and W dir wsmouse1 at ums1 mux 0 uhid2 at uhidev4 reportid 3: input=4, output=0, feature=0 uhid3 at uhidev4 reportid 4: input=1, output=0, feature=0 uhid4 at uhidev4 reportid 8: input=1, output=0, feature=0 uhidev5 at uhub5 port 3 configuration 1 interface 2 "Logitech USB Receiver" rev 2.00/12.07 addr 3 uhidev5: iclass 3/0, 33 report ids uhid5 at uhidev5 reportid 16: input=6, output=6, feature=0 uhid6 at uhidev5 reportid 17: input=19, output=19, feature=0 uhid7 at uhidev5 reportid 32: input=14, output=14, feature=0 uhid8 at uhidev5 reportid 33: input=31, output=31, feature=0 uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB OPTICAL MOUSE" rev 1.10/1.00 addr 3 uhidev6: iclass 3/1, 1 report id ums2 at uhidev6 reportid 1: 3 buttons, Z dir wsmouse2 at ums2 mux 0 wsmouse2 detached ums2 detached uhidev6 detached uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB OPTICAL MOUSE" rev 1.10/1.00 addr 3 uhidev6: iclass 3/1, 1 report id ums2 at uhidev6 reportid 1: 3 buttons, Z dir wsmouse2 at ums2 mux 0 wsmouse2 detached ums2 detached uhidev6 detached uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB OPTICAL MOUSE" rev 1.10/1.00 addr 3 uhidev6: iclass 3/1, 1 report id ums2 at uhidev6 reportid 1: 3 buttons, Z dir wsmouse2 at ums2 mux 0 wsmouse2 detached ums2 detached uhidev6 detached uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB OPTICAL MOUSE" rev 1.10/1.00 addr 3 uhidev6: iclass 3/1, 1 report id ums2 at uhidev6 reportid 1: 3 buttons, Z dir wsmouse2 at ums2 mux 0 wsmouse2 detached ums2 detached uhidev6 detached uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB OPTICAL MOUSE" rev 1.10/1.00 addr 3 uhidev6: iclass 3/1, 1 report id ums2 at uhidev6 reportid 1: 3 buttons, Z dir wsmouse2 at ums2 mux 0 wsmouse2 detached ums2 detached uhidev6 detached uhidev6 at uhub0 port 4 configuration 1 interface 0 "vendor 0x USB OPTICAL MOUSE" rev 1.10/1.00 addr 3 uhidev6: iclass 3/1, 1 report id ums2 at uhidev6 reportid 1: 3 buttons, Z dir
Re: How did it happen?
Really great article. Was very fun to read. And again thanks for your work on osmtpd, am actually sending from a server set up from your poolp post :D Sucks about the bug, but logic errors are the wurst. Take care. --- Aisha blog.aisha.cc On 2020-01-31 13:48, gil...@poolp.org wrote: January 30, 2020 4:44 PM, gil...@poolp.org wrote: It depends on your configuration, not all setups are vulnerable. I think I recall your name from the comments on my tutorial and this is a setup that would not be vulnerable for example. The bug still exists, but it can't be used to exploit the same code path. You should update, this is not something you want to rely on. I'm writing a _very_ detailed post-mortem which will go into the details, I just want to give it a few days to make sure it is as informative as it should. As promised, I have written a (too much ?) detailed write-up about the recent event: https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/ Hope it clarifies what happened and plans for the future. Gilles
Re: How did it happen?
January 30, 2020 4:44 PM, gil...@poolp.org wrote: > It depends on your configuration, not all setups are vulnerable. > > I think I recall your name from the comments on my tutorial and this is a > setup that would not be vulnerable for example. The bug still exists, but > it can't be used to exploit the same code path. > > You should update, this is not something you want to rely on. > > I'm writing a _very_ detailed post-mortem which will go into the details, > I just want to give it a few days to make sure it is as informative as it > should. > As promised, I have written a (too much ?) detailed write-up about the recent event: https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/ Hope it clarifies what happened and plans for the future. Gilles
Re: FreeBSD daemon(8)-like command for OpenBSD
Hi Patrick, Patrick Kristiansen wrote on Fri, Jan 31, 2020 at 10:17:35AM +0100: > Trying to learn some valuable lessons from our interaction, could you > give some examples of what you mean by 'simpler approach' in this > context? Three examples: https://learnbchs.org/ https://man.openbsd.org/man.cgi -- this one written from scratch without any framework https://man.openbsd.org/bgplg > Do you mostly do systems programming? https://mandoc.bsd.lv/press.html and also see my various CV abstracts for BSDCan. Yours, Ingo
Recovering corrupted encrypted partition
Hello, Recently my 6.6-stable machine lost power while on, which aparently corrupted a softraid crypto partition (not a boot partition) that was mounted. Trying to decrypt it with the same bioctl command i usually use fails with the error: softraid0: invalid metadata format I tried bioctl's "-R" and "-C force" options, which fail with the same error. After searching all over the mailing list archives, I couldn't find a solution that didn't destroy data. Some people suggested zeroing the first megabyte and reconfiguring the disklabel, but I'm not sure if that would overwrite my existing data. It seems that recovering the partition itself is not easy/possible at the moment. However, could I manually decrypt the data? I tried running openssl enc -d -aes-256-xts -salt -k at numerous byte offsets from the start of the partition, but so far it has been failing with the error "bad magic number". Any other ideas?
Re: FreeBSD daemon(8)-like command for OpenBSD
Hi Andrew, Andrew Easton wrote on Fri, Jan 31, 2020 at 11:39:45AM +0100: > In the spirit of not demanding to much time from my contemporaries I > am especially greatful for pointers to conceptual documentation This is the closest thing, i guess: https://www.openbsd.org/events.html In general, to save time, the OpenBSD projects maintains only concise reference documentation, not introductory documents or tutorials. > and to implementation documentation. For the kernel in general, see section 9 in man(1). For userland programs, implementation documentation does not exist in general, though there are are a few rare exceptions, see for example the manual pages "For programmers:" listed on https://mandoc.bsd.lv/ and some very rare text files scattered around the source tree - but be careful, some of these can be seriously outdated. In general, our recommendation is RTFS (read the fantastic source code). Specifically, i'm not convinced that implementation documentation exists for pledge(2) or unveil(2), but i may have missed something. > [[ I have the suspicion that being a good programmer crucially depends > on having conceptual understanding. Maybe it also depends on practice.]] Many of us develop their conceptual understanding from reading source code and from practice. > Concretely: > Just to start off easy, how can I find conceptual documentation on > what an operating system "process" is in OpenBSD While various details about how the kernel manages processes are no doubt OS-specific, the conceptual ideas are probably more or less common to all Unix implementations. For the basics, standard text books may be useful, as found on https://www.openbsd.org/books.html , for example Kirk's classic "Design and Implementation of the 4.4BSD Operating System". > and how deeply a libc > is tied into that by design? As far as I am aware a process has the > "current working directory" associated with it, in order to be able to > resolve relative paths and is also where "environment variables" are > stored. These remind me of dynamic bindings, at least in spirit. I am > only aware of plain C having lexical bindings, in contrast to this. For such details, our recommendation generally is "read the source". Start from the section 2 and 3 manual pages of the functions you are interested in. Then, if you need more details about how it's implemented, read the libc code. Then, if you need even more details, read the code handling the syscalls in the kernel, of those syscalls that are used in the libc implementation. As opposed to the mess you are maybe used to from glibc, OpenBSD code is generally very concise and readable. Yours, Ingo
What are xxxterm users using today?
I used to use xxxterm, then xombrero, and really liked the minimal approach and keyboard driven navigation. Any other former users of this browser, what are you using today to achieve any of this functionality in your browser? Allan
syspatch(8) return values?
There's no mention of what syspatch(8) returns, in the manpage. I can prove quickly enough that it exits(0) when there's nothing to do, but I'm more interested in knowing (for automation purposes) what the return values are in other circumstances, and all my systems are already up to date. Before standing up yet another system, I figured I'd ask here. I can think of four scenarios syspatch(8) perhaps ought to distinguish, at least I'm interested in these 4 outcomes: 1. nothing to do 2. patches waiting, but didn't do anthing 3. patches applied 4. something went wrong Can I reliably tell based on $? or do I have to parse the output? Thanks, -Adam
Re: FreeBSD daemon(8)-like command for OpenBSD
The list might not like this but: Under your circumstances, I would collect the various ideas in this thread (including scripting possibly with nohup and/or bash's disown), the "pgrep || " idea somebody wrote, and whatever else is useful from the thread, and just make it work with careful testing of different failure scenarios. I found that when writing a cron job I had to test very carefully if different things failed about it, before I actually got it right. Logs can be done with things like > somefile.log 2>&1 ...or variations, and if you then check it occasionally to see that it is working, learn, move on, things can probably work out. Then if it is ever rewritten in a way that allows doing the things Ingo suggests, use his suggestions. In the meantime, isolate it well to prevent security breaches from affecting other things (ie, considering what could be affected if/when it is compromised, make sure those other things are minimized). Sometimes the cost/benefit realities (or employers) force choices upon us. -- Please pray for our country(ies) and leaders, at this important time. More on this and other topics (a simple site w/o sales): http://lukecall.net (updated 2020-01-23) On 01-30 21:05, Patrick Kristiansen wrote: > Hi Ingo, > > On Thu, Jan 30, 2020, at 18:35, Ingo Schwarze wrote: > > Hi Patrick, > > > > Patrick Kristiansen wrote on Tue, Jan 28, 2020 at 09:29:20AM +0100: > > > > > But another use for daemon(8) is for its ability to detach the child > > > process from the controlling terminal and furthermore redirect its > > > stdout/stderr to syslog. Is there some mechanism to do that from the > > > shell? Perhaps a combination of nohup and starting a background job? > > > > That doesn't strike me as a particularly bright idea either. > > > > Properly starting up a daemon process requires several steps, often > > involving unveil(2), pledge(2), chroot(2), prviledge dropping, > > sometimes fork+exec for privilege separation, and so on. Typically, > > these steps need to be intermixed in exactly the right order with > > option parsing, environment parsing, parsing of configuration files > > and various kinds of initialization. > > The process I need to run is written in Clojure and thus runs on the > Java Virtual Machine. Do you have any suggestions on how to best go > about making it "daemon-like"? I am not sure that I can call unveil(2), > pledge(2) and chroot(2) from Clojure without some strange sorcery. I > read in some blog post, that the way to detach from the controlling > terminal is by closing stdin, stdout and stderr, which I admittedly > haven't tried. > > > Writing wrappers usually just doesn't work, and it seems doubtful to > > me whether daemon(8) is up to what is usually needed. > > If I were writing my program in C, I could fairly easily call daemon(3), > I guess, but I am not. I am starting to think that tmux(1) would be the > easiest way to go about it on OpenBSD... but it feels wrong. > > Best regards, > Patrick >
ssh: switch UpdateHostKeys default back to "no" in ssh -current
Namaste misc, Could I request the ssh volks to please switch the default for UpdateHostKeys back to "no"? The default for UpdateHostKeys has been very recently switched to "ask" from the earlier default of "no" in rev 1.323 of the file src/usr.bin/ssh/readconf.c [1]. This default has been further switched to "yes" in rev 1.324, if only the default known_hosts files are in use, or "ask" in case of non-default known_hosts files [2]. Key rotation is a challenge, and it is great that OpenSSH has the ability to assist in this. And those who wish to, can set their client configs to "ask" or "yes". But I am not sure that switching the default to "yes" or "ask"[3] for everyone is advisable. I (n=1) think it is preferable for the ssh client to only read from the known hosts file, and the updates to that file be handled outside the ssh system. To my mind, "yes" seems like auto-magic. As an example, in the case that I outlined in my recent bug report [4], if not for the check in host_delete function, the host certificate authority public key would have been removed from the client known_hosts files. Dhanyavaad, ab [1] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c.diff?r1=1.322=1.323=h [2] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c.diff?r1=1.323=1.324=h [3] - The "ask" is equivalent to "yes" in operational terms - users say "yes" - Always. No exceptions (TrainedByWindows(c)(TM)). [4] - https://marc.info/?l=openbsd-misc=158047930331003=2 -|-|-|-|-|-|-|--
ssh: probable minor bug in ssh -current
Namaste misc,
Overview:
In update_known_hosts function in file src/usr.bin/ssh/clientloop.c [1],
the message strings used in debug and error functions may need to be
changed.
Bug:
In src/usr.bin/ssh/clientloop.c,
...
static void
update_known_hosts(struct hostkeys_update_ctx *ctx)
{
...
if (errno == ENOENT) {
debug("%s: known hosts file %s does not exist",
__func__, strerror(errno));
} else {
error("%s: known hosts file %s inaccessible",
__func__, strerror(errno));
}
...
}
...
the message strings for debug and error functions do not seem to be
correct.
Do we want to:
1) print the name of the file which does not exist/is inaccessible,
2) print the string representation of the errno,
3) both of the above.
This code was recently added in the revision 1.333 [2].
Dhanyavaad,
ab
[1] -
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/clientloop.c?rev=1.338=text/x-cvsweb-markup
[2] -
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/clientloop.c.diff?r1=1.332=1.333=h
-|-|-|-|-|-|-|--
ssh: probable bug in ssh -current
Namaste misc, Overview: In -current (#625), the ssh client is asking the user to accept updated server host keys after every successful connection. No host keys have actually been updated at the server side. Setup: Consider a server (-current #625) which uses host certificates. The server's ed25519 host public key is signed by a host certificate authority. Consider a client (-current #625) which is configured to use only ed25519-cert and ed25519 HostKeyAlgorithms. In its known hosts file, the client has @cert-authority ssh-ed25519 ssh-ed25519 . Bug: When the client connects to the server, they use the ed25519-cert to establish the connection. After the ssh session is established, the server sends the "hostkeys...@openssh.com" message with the server's ed25519 host public key. This results in the client looping over the keys in known hosts file, and deciding that the @cert-authority host certificate authority public key is "deprecated", because it was not sent by the server [1]. The client then informs the user: " The server has updated its host keys. These changes were verified by the server's existing trusted key. Deprecating obsolete hostkey: ED25519 SHA256: Accept updated hostkeys? (yes/no): " In reality, no host key has been added/removed on the server. Repeat. No host key has been added/removed on the server. Now, even when the user types yes in response to the above prompt, the user is presented with this prompt again after the next successful login. This is because when the user types yes, there is a check in the host_delete function in src/usr.bin/ssh/hostfile.c, which prevents the @cert-authority keys from being deleted [2]. goto Bug: after every successful login. And if I am not wrong, this "ask" happened due to the recent changes in the default setting of UpdateHostKeys option [3][4]. (It is only when users are repeatedly prompted with the same question by ssh, some get annoyed, few irritated, one complains. And because we had not changed any keys, and updated everyone+dog to the recent -current because of the smtpd CVE, it set alarm bells ringing so as to whether "someone" had actually changed the keys.) Dhanyavaad, ab [1] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/clientloop.c?rev=1.338=text/x-cvsweb-markup [2] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/hostfile.c?rev=1.77=text/x-cvsweb-markup [3] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c.diff?r1=1.322=1.323=h [4] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c.diff?r1=1.323=1.324=h -|-|-|-|-|-|-|--
Open BSD 6.6 Gnome 3.3
Shout out to Theo DeRaadt and the OpenBSD Developers for making a great operating system. I have OpenBSD 6.6 Current with Gnome 3.3 running on a Dell Vostro Laptop with an SSD drive, and it runs great. However, every time I run Chromium web browser, I get prompted UNLOCK using a password. Very annoying, I did not find much on a Google or Bing search on how to get rid of the password prompt. I found one blog entry saying to use seahorse to delete the passwords, I installed seahorse, deleted the passwords, but every time I restart chromium, chromium readds the passwords. Does anyone know a solution to this? this never occurred when using FVWM window manager on the same laptop, so suspect it is Gnome that is causing this. Thanks. *Michael G. Workman* (321) 432-9295 michael.g.work...@gmail.com
Re: FreeBSD daemon(8)-like command for OpenBSD
On 2020-01-31 12:16, KatolaZ wrote: > For instance, golang has had native support > for pledge(2) and unveil(2) for a while now. The semantics are a little different to C unveil but it certainly works and bundled by default in the golang.org/x. Not sure the documentation is great. It's a little ironic that whilst golangs smallest binary (ignoring tinygo) is > 2 megabytes preventing generic use. One of the main incentives for it's initial development was to have something somewhat like C whilst avoiding compiling unused dependencies and speedup build times. It has found a good place between C and the montrosity of java and I expect will replace java slowly but likely not C. Unless unix dies from the systemd treatment (I'm confident it won't in OpenBSD)
Re: FreeBSD daemon(8)-like command for OpenBSD
On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote: [cut] > > I would like to get more information about doing application programming > for an OS like OpenBSD. I understand that if you program your > applications in C, you have readily available pledge/unveil, etc. But > many applications are written in higher-level languages, and in my case > at least, it seems to be nearly impossible to write a secure application > without changing to C or some other language that can easily use > OpenBSD's system calls. And for a mediocre programmer, or just an > inexperienced one, it exposes you to a whole host of other problems that > can lead to worse security and quality. > Some "high-level" languages have support for some of the OpenBSD-specific syscalls. For instance, golang has had native support for pledge(2) and unveil(2) for a while now. I don't know if the source is authoritative and I am not related to the author in any way, but there is also a list of which languages support those syscalls at: https://gist.github.com/ligurio/f6114bd1df371047dd80ea9b8a55c104 note that in some cases the support is available from third-parties modules. HTH
Re: Low throughput with 1 GigE interface
On Thu, January 30, 2020 11:43, livio wrote: > Dear all, > > I am unable to achieve decent throughput with a 1 GigE interface > (Intel I210) on OpenBSD 6.6. When running iperf3 I get around 145Mbit/s. > > The config/setup is: APU2c4, Win10 notebook, no switch, Cat.6a cable, > MTU 1500, 1000baseT, full-duplex, pf disabled, BSD.mp, no custom Kernel > parameters/optimizations. > > With an increased MTU of 9000 (on both devices) the throughput is around > 230-250Mbit/s. > > When running the same test with a FreeBSD 12.1 on the APU I achieve > around 940Mbit/s (MTU 1500). > > The BIOS has been updated to the latest version (v4.11.0.2). The > hardware of the device is: https://pcengines.ch/apu2c0.htm > > dmesg output: > https://paste.ee/p/OeRbI > > Any inputs and help is highly appreciated. > > Many thanks, > Livio > > PS: I ran the same tests on an APU1c4 with Realtek RTL8111E interfaces. > The results were lower - around 95Mbit/s. > https://pcengines.ch/apu1c4.htm > > PPS: Others also seem to have low throughput. None of the tuning > recommendations I found online substantially improved my results: > https://www.reddit.com/r/openbsd/comments/cg9vhq/poor_network_performance_pcengines_apu4/ I would cut Windows from it. I always get lower numbers when it is on one end of the test. I know FreeBSD got higher results, would cut anyway. Try one APU to the other. Did already? matheus -- "We will call you Cygnus, the God of balance you shall be."
Re: FreeBSD daemon(8)-like command for OpenBSD
Den fre 31 jan. 2020 kl 11:48 skrev Andrew Easton : > On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote: > > On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote: > > > Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen < > patr...@tamstrup.dk>: > > > > > Properly starting up a daemon process requires several steps, > > > > > often involving unveil(2), pledge(2), chroot(2), prviledge > > > > > dropping, sometimes fork+exec for privilege separation, and so on > > > > > > > > The process I need to run is written in Clojure and thus runs on the > > > > Java Virtual Machine. Do you have any suggestions on how to best go > > > > about making it "daemon-like"? I am not sure that I can call > unveil(2), > > > > pledge(2) and chroot(2) from Clojure without some strange sorcery. > > For the record, I am also interested in information on how pledge(2) and > unveil(2) would interact with a "higher level language". man OpenBSD::Pledge will show how you call pledge from perl (if you accept that as a higher level language in this case), and it works mostly because perl will not silently have tons of secret underlying operations so that when you ask perl to concatenate two strings, it will not open sockets and pipe them to itself in order to do that, or write them to $TEMPDIR or some other possible construct in order to make a simple operation suddenly require file system access or socket binding capacity. The more weird (or generic) your runtime is, the less chances will you get to be able to say "from now on, I will not open any more files, sockets or call reboot()" because the runtime may just do one of those, when garbage collecting or something. > I would also > be happy to learn more about how they interact with assembly. > I'm sure they interact equally well as with C, given that the C program that calls pledge/unveil at that time is assembler. > Concretely: > Just to start off easy, how can I find conceptual documentation on > what an operating system "process" is in OpenBSD and how deeply a libc > is tied into that by design? As far as I am aware a process has the > libc isn't all that tied to a process, it's just that libc contains some very neat and useful functions (like wrapping calloc() over malloc()/mmap() so the kernel only exposes one single way for a process to allocate memory, but libc can still implement realloc(), calloc() and so on for you, using normal code and the give-me-some-pages-of-RAM syscall. > "current working directory" associated with it, in order to be able to > resolve relative paths and is also where "environment variables" are > stored. Well, you can still reach the environment without libc, but libc makes it easier for you, just like with the something*alloc() routines. > > (I am also still fuzzy on how intertwined an operating system and a CPU > are. From my superficial understanding, e.g. the operating system has > to be aware of the MMU. I think that is a completely separate dimension, but yes, given that the OS controls and commands the MMU to do various things, it most certainly is "aware" of it. -- May the most significant bit of your life be positive.
Re: FreeBSD daemon(8)-like command for OpenBSD
On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote: > On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote: > > Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen > > : > > > > Properly starting up a daemon process requires several steps, > > > > often involving unveil(2), pledge(2), chroot(2), prviledge > > > > dropping, sometimes fork+exec for privilege separation, and so on > > > > > > The process I need to run is written in Clojure and thus runs on the > > > Java Virtual Machine. Do you have any suggestions on how to best go > > > about making it "daemon-like"? I am not sure that I can call unveil(2), > > > pledge(2) and chroot(2) from Clojure without some strange sorcery. > > > > So not related to only Clojure but rather on runtimes that are large > > and unwieldy, this seems to be exactly why plegde() and unveil() came > > into being in the first place, after seeing things that needs to do > > certain privileged operations at some early point, but because of > > design/runtime/hard-to-pledge or whatever has to run with the sum of > > all privileges, all capabilities at all times and at the same time > > being exposed to potential hostile data. > > Yes. I completely understand the motivation behind pledge, unveil and > similar constructs. I also understand that it sort of runs counter to > using one of the world's most secure-by-default operating systems if you > then run an insecure monstrosity on top of it. I was just starting to > like the OpenBSD experience as a user and sysadmin. :-) > > But I also think that it is unrealistic to expect applications to be > written to the same standard as OpenBSD, given the resources needed for > that. Many startups would never get off the ground if that were the > case. > > > I can fully see why Ingo would say "I would not run things like that > > exposed", partly because I figure he actually has a choice to not do > > it, but regardless of what electric fences you like (Selinux, > > capsicum, pledge/unveil, chroots) if you create a huge monolith > > running in an environment which actively prevents you from activating > > any kinds of protections, then I can see how you would see some > > friction. > > I would like to get more information about doing application programming > for an OS like OpenBSD. I understand that if you program your > applications in C, you have readily available pledge/unveil, etc. But > many applications are written in higher-level languages, and in my case > at least, it seems to be nearly impossible to write a secure application > without changing to C or some other language that can easily use > OpenBSD's system calls. And for a mediocre programmer, or just an > inexperienced one, it exposes you to a whole host of other problems that > can lead to worse security and quality. > > The solution is probably just to be a good programmer. ;-) > For the record, I am also interested in information on how pledge(2) and unveil(2) would interact with a "higher level language". I would also be happy to learn more about how they interact with assembly. My conceptual understanding can probably still be improved upon. In the spirit of not demanding to much time from my contemporaries I am especially greatful for pointers to conceptual documentation and to implementation documentation. I have the impression that it seems effective to get a conceptual overview first. [[ I have the suspicion that being a good programmer crucially depends on having conceptual understanding. Maybe it also depends on practice.]] Concretely: Just to start off easy, how can I find conceptual documentation on what an operating system "process" is in OpenBSD and how deeply a libc is tied into that by design? As far as I am aware a process has the "current working directory" associated with it, in order to be able to resolve relative paths and is also where "environment variables" are stored. These remind me of dynamic bindings, at least in spirit. I am only aware of plain C having lexical bindings, in contrast to this. (I am also still fuzzy on how intertwined an operating system and a CPU are. From my superficial understanding, e.g. the operating system has to be aware of the MMU. I am concretely speaking of amd64 territory here.) https://man.openbsd.org/process : did not turn up anything https://man.openbsd.org/pledge : where is further information on what a process is? https://man.openbsd.org/unveil : where is further information on what a process is? Best Regards, Andrew
Re: FreeBSD daemon(8)-like command for OpenBSD
On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote: > Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen > : > > > Properly starting up a daemon process requires several steps, > > > often involving unveil(2), pledge(2), chroot(2), prviledge > > > dropping, sometimes fork+exec for privilege separation, and so on > > > > The process I need to run is written in Clojure and thus runs on the > > Java Virtual Machine. Do you have any suggestions on how to best go > > about making it "daemon-like"? I am not sure that I can call unveil(2), > > pledge(2) and chroot(2) from Clojure without some strange sorcery. > > So not related to only Clojure but rather on runtimes that are large > and unwieldy, this seems to be exactly why plegde() and unveil() came > into being in the first place, after seeing things that needs to do > certain privileged operations at some early point, but because of > design/runtime/hard-to-pledge or whatever has to run with the sum of > all privileges, all capabilities at all times and at the same time > being exposed to potential hostile data. Yes. I completely understand the motivation behind pledge, unveil and similar constructs. I also understand that it sort of runs counter to using one of the world's most secure-by-default operating systems if you then run an insecure monstrosity on top of it. I was just starting to like the OpenBSD experience as a user and sysadmin. :-) But I also think that it is unrealistic to expect applications to be written to the same standard as OpenBSD, given the resources needed for that. Many startups would never get off the ground if that were the case. > I can fully see why Ingo would say "I would not run things like that > exposed", partly because I figure he actually has a choice to not do > it, but regardless of what electric fences you like (Selinux, > capsicum, pledge/unveil, chroots) if you create a huge monolith > running in an environment which actively prevents you from activating > any kinds of protections, then I can see how you would see some > friction. I would like to get more information about doing application programming for an OS like OpenBSD. I understand that if you program your applications in C, you have readily available pledge/unveil, etc. But many applications are written in higher-level languages, and in my case at least, it seems to be nearly impossible to write a secure application without changing to C or some other language that can easily use OpenBSD's system calls. And for a mediocre programmer, or just an inexperienced one, it exposes you to a whole host of other problems that can lead to worse security and quality. The solution is probably just to be a good programmer. ;-)
Re: FreeBSD daemon(8)-like command for OpenBSD
On Thu, Jan 30, 2020, at 23:32, Ingo Schwarze wrote: > In general, size and complexity tend to hurt security, but i know > too little about Java to say how relevant that general rule of thumb > is to the question of running a daemon using a Java Virtual Machine. > For example, Perl 5 is also a fairly large and complex system, but > it still supports writing daemons that are secure enough for many > purposes, when used properly - even though i'd probably prefer a > simpler approach when i have a choice. Trying to learn some valuable lessons from our interaction, could you give some examples of what you mean by 'simpler approach' in this context? Do you mostly do systems programming? Best regards, Patrick
Re: FreeBSD daemon(8)-like command for OpenBSD
Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen < patr...@tamstrup.dk>: > > Properly starting up a daemon process requires several steps, often > > involving unveil(2), pledge(2), chroot(2), prviledge dropping, > > sometimes fork+exec for privilege separation, and so on > > The process I need to run is written in Clojure and thus runs on the > Java Virtual Machine. Do you have any suggestions on how to best go > about making it "daemon-like"? I am not sure that I can call unveil(2), > pledge(2) and chroot(2) from Clojure without some strange sorcery. So not related to only Clojure but rather on runtimes that are large and unwieldy, this seems to be exactly why plegde() and unveil() came into being in the first place, after seeing things that needs to do certain privileged operations at some early point, but because of design/runtime/hard-to-pledge or whatever has to run with the sum of all privileges, all capabilities at all times and at the same time being exposed to potential hostile data. I can fully see why Ingo would say "I would not run things like that exposed", partly because I figure he actually has a choice to not do it, but regardless of what electric fences you like (Selinux, capsicum, pledge/unveil, chroots) if you create a huge monolith running in an environment which actively prevents you from activating any kinds of protections, then I can see how you would see some friction. -- May the most significant bit of your life be positive.
