Re: Setuid changed on /sbin/ping after installing patch 022_resolv

[tetrahedra]

Thank you for clarifying! Yes, I misunderstood what was meant by setuid
change, it makes sense it is checking for any change in a setuid binary.

It may be worth changing the wording in the security(8) message from
Setuid changes:
to
Changed setuid binaries:
as this would eliminate ambiguity. ("is it a change in a setuid bit or a
change in a binary that is already setuid?")

On Tue, Apr 11, 2023 at 08:52:09AM -0600, Theo de Raadt wrote:

the man page says:

o   Check for changes in setuid/setgid files and devices.

Those setuid binaries did change.  They were replaced. The sizes
are different also.  That's because there is a libc.a change and
these are static binaries.

the security script is not not just reporting whether setuid bits
are being turned on or off.


tetrahe...@danwin1210.de wrote:


Hi all,
security(8) sent me an alert that Setuid changed on /sbin/ping and
/sbin/ping6:

Running security(8):

Setuid changes:
-r-sr-xr-x 2 root bin 347728 Sep 27 17:40:01 2022 /sbin/ping
-r-sr-xr-x 1 root bin 347776 Mar 11 19:42:17 2023 /sbin/ping
-r-sr-xr-x 2 root bin 347728 Sep 27 17:40:01 2022 /sbin/ping6
-r-sr-xr-x 1 root bin 347776 Mar 11 19:42:17 2023 /sbin/ping6


This happened after I installed syspatch 022_resolv (and made no other
changes to the system).

I checked the source code of the 022_resolv patch and I don't see
anything that would affect the /sbin/ping binary.

Did I miss something? Or is this setuid change potentially indicative of
a bigger problem?

Setuid changed on /sbin/ping after installing patch 022_resolv

[tetrahedra]

Hi all,
security(8) sent me an alert that Setuid changed on /sbin/ping and
/sbin/ping6:

Running security(8):

Setuid changes:
-r-sr-xr-x 2 root bin 347728 Sep 27 17:40:01 2022 /sbin/ping
-r-sr-xr-x 1 root bin 347776 Mar 11 19:42:17 2023 /sbin/ping
-r-sr-xr-x 2 root bin 347728 Sep 27 17:40:01 2022 /sbin/ping6
-r-sr-xr-x 1 root bin 347776 Mar 11 19:42:17 2023 /sbin/ping6


This happened after I installed syspatch 022_resolv (and made no other
changes to the system).

I checked the source code of the 022_resolv patch and I don't see
anything that would affect the /sbin/ping binary.

Did I miss something? Or is this setuid change potentially indicative of
a bigger problem?

Re: How does bsd.upgrade work?

[tetrahedra]

On Thu, Oct 21, 2021 at 03:46:20PM +0200, Janne Johansson wrote:

https://marc.info/?l=openbsd-tech=138829898720574=2
and
https://marc.info/?l=openbsd-tech=139013674405106=2
might help.


Thanks. This is the critical section:
https://github.com/openbsd/src/blob/9c70cf5498e471044289f4c9857b84b309c5964e/sys/dev/rnd.c#L44-L45

So if the volume with the bootloader on it is not booted, the RNG is
intialised with a less-random value (in particular if a hardware RNG is
not present).

On Linux it's possible to check for an Intel hardware RNG[1] by looking
for `rdrand` in /proc/cpuinfo[2]. *BSD seems to split this across
`sysctl hw`, dmesg, and `dmidecode` [3].

Does this sound right -- will OpenBSD use the `rdrand` instruction if
present, early in the boot process?

[1]
https://stackoverflow.com/questions/26771329/is-there-any-legitimate-use-for-intels-rdrand

[2]
https://0f5f.blogs.minster.io/2015/10/leveraging-intel-ivy-bridges-hardware-rng/

[3]
https://stackoverflow.com/questions/4083848/what-is-the-equivalent-of-proc-cpuinfo-on-freebsd-v8-1

Re: How does bsd.upgrade work?

[tetrahedra]

On Tue, Oct 19, 2021 at 09:32:21PM +0100, Stuart Henderson wrote:

That's intentional.


OK. Since you didn't realise this breaks sysupgrade you might also
not realise it weakens RNG initialisation, it is not recommended


Where can I read more about this?

Re: How does bsd.upgrade work?

[tetrahedra]

On Mon, Oct 18, 2021 at 05:41:26PM +0200, Florian Obser wrote:

I wouldn't call this "resolved". You are missing the point that
bsd.upgrade should run automatically. *shrug*


My setup is not standard, so it's normal that bsd.upgrade not run
automatically. The solution I used, as far as I know, is by far the
simplest and easiest way of resolving the problem.

Re: How does bsd.upgrade work?

[tetrahedra]

On Mon, Oct 18, 2021 at 07:41:57PM -, Stuart Henderson wrote:

I resolved the problem. The solution was to run `sysupgrade -n` to
download all the upgrade files, and leave the `bsd.upgrade` kernel in
place, next to the `bsd` kernel I usually boot.

Then, at the next boot, manually boot the `bsd.upgrade` kernel by
specifying its location.


Sounds like you aren't using the correct boot loader.


That's intentional.

Re: How does bsd.upgrade work?

[tetrahedra]

On Fri, Oct 15, 2021 at 10:14:56PM +, tetrahe...@danwin1210.me wrote:

My setup is a little bit unusual, and I'm trying to understand why
`uname -a` is still reporting 6.9 after I successfully booted
bsd.upgrade and saw the upgrade process scroll past.


I resolved the problem. The solution was to run `sysupgrade -n` to
download all the upgrade files, and leave the `bsd.upgrade` kernel in
place, next to the `bsd` kernel I usually boot.

Then, at the next boot, manually boot the `bsd.upgrade` kernel by
specifying its location.

Re: How does bsd.upgrade work?

[tetrahedra]

On Sat, Oct 16, 2021 at 10:28:33AM -, Stuart Henderson wrote:

The boot loader looks for /bsd.upgrade with 'x' filesystem permissions.
If present it removes the x flag and boots. (I think this should be
documented in boot(8) for the various arch but is missing).


I agree.


The install kernel looks for /auto_upgrade.conf (written by sysupgrade)
to use as a response file for the autoinstall(8) mechanism.


My setup is a little bit unusual, and I'm trying to understand why
`uname -a` is still reporting 6.9 after I successfully booted
bsd.upgrade and saw the upgrade process scroll past.


The email sent to root ("$hostname upgrade log") may contain
useful information.


Thanks. I see what looks like a partial log, it couldn't find the sets
in /mnt/home/_sysupgrade and seems to have terminated at that point.


For an unusual setup you may need to look into how the
install/upgrade script works, see /usr/src/distrib/miniroot.


/usr/src/ is empty on my machine.

How does bsd.upgrade work?

[tetrahedra]

It's not documented in the `sysupgrade` manpage.

My setup is a little bit unusual, and I'm trying to understand why
`uname -a` is still reporting 6.9 after I successfully booted
bsd.upgrade and saw the upgrade process scroll past.

Re: Minimum RAM for Chrome

[tetrahedra]

On Sat, Aug 07, 2021 at 01:15:52PM -, Stuart Henderson wrote:

Am I running into system memory limits ("minimum 8GB RAM to surf the
web"? what is the world coming to?) or is another issue likely the
cause?


I wouldn't rule that possibility out… I manage with Firefox on Linux
with a 2GB netbook, but only just: some websites just eat RAM like it's
going out of fashion.  Playing videos definitely makes the problem
worse.  Comparatively "simple" websites work okay but anything that's
real-time: all bets are off!

I haven't tried OpenBSD on the same machine, but I suspect the problem
isn't limited to browser or OS.  Your mileage will definitely depend on
the sort of website you frequently like to visit.


OpenBSD doesn't do brilliantly with swapping.


Thanks. That's all rather depressing...

Minimum RAM for Chrome

[tetrahedra]

I've got a spare laptop that I use for web browsing. Since it only has
4GB RAM, OpenBSD seemed a good fit for it.

However Chrome is extremely slow. I've increased system resource limits
as mentioned in the email list archives, but that didn't resolve the
issue.

If I turn off video acceleration blacklisting in Chrome, videos play
faster but starting the browser takes ages and sometimes fails entirely.
Regardless, there is still lots of lag when loading pages.

Am I running into system memory limits ("minimum 8GB RAM to surf the
web"? what is the world coming to?) or is another issue likely the
cause?

Packages/libraries in disarray after sysupgrade

[tetrahedra]

After upgrading 6.8->6.9 (stable, not current) using sysupgrade, I am 
finding it not possible to install packages via pkg_add


When I try to install something, I get a series of errors like "dependency library name>: bad major" or ": minor is 
too small"


I am assuming I need to be installing new packages with `pkg_add -U` to 
update the dependencies as needed. However, the manpage suggests this is 
not desirable.


Is there a better way to do things?

Re:

[tetrahedra]

Hi, you need to recreate, unfortunately. This has been discussed before, 
if you search the archives for my email address you will find the 
discussion :)



On Sat, May 01, 2021 at 01:39:58PM +0300, Irshad Sulaiman wrote:

Hi


is it possible to change from passphrase to key disk in
bictl (8) , or do I need to recreate whole RAID again


Thank you
Etchers

Re: .profile not being loaded (ksh) when opening shell in X

[tetrahedra]

On Tue, Apr 27, 2021 at 09:37:05AM +0200, Alexandre Ratchov wrote:

If you're using a display manager (xenodm or whatever), you've to
include your .profile in your session login script (X equivalent of
shell's ~/.profile concept), so the envoronment (and other global
login settings) from your .profile become visible to all X programs,
not only xterm. For instance put:

. ~/.profile

at the beginning of our ~/.xsession

If you're using xinit(1), your ~/.profile is already loaded by
the login shell.


That seems the right way to go, if the other suggested solution of 
defining ENV doesn't do the trick.

Re: .profile not being loaded (ksh) when opening shell in X

[tetrahedra]

On Tue, Apr 27, 2021 at 08:04:32AM +0300, Pierre-Philipp Braun wrote:

Could also just source your profile in your .xsession. That's what I'm in the
habit of doing.


I believe there's no need for neither login-shells nor those X-level 
tricks.  To load the interactive environment into xterms or screen, I 
usually to define ENV accordingly in /etc/profile or .profile.  Not 
sure it's the right way to also put PATH in (k)shrc, but it would also 
work.


/etc/profile: export ENV=/etc/shrc

or

~/.profile: export ENV=/root/.shrc


That's very interesting. Can someone explain what this does?

Re: .profile not being loaded (ksh) when opening shell in X

[tetrahedra]

On Mon, Apr 26, 2021 at 05:46:14PM -0400, Allan Streib wrote:

"tetrahe...@danwin1210.me"  writes:


It looks like the custom $PATH is not being passed from the login shell
on downwards, since ~/.profile is only read by a login shell.


I just was looking into the same thing last night. The ksh shell in the
xterm didn't seem to be processing my .profile. Adding the '-ls'
argument to the xterm command resolved that.

  -ls This option indicates that the shell that is started in the
  xterm window will be a login shell (i.e., the first character
  of argv[0] will be a dash, indicating to the shell that it
  should read the user's .login or .profile).


Thanks. Yes, that would work, but I feel like the contents of ~/.profile 
should be available to other commands as well, not just the xterm 
window.

.profile not being loaded (ksh) when opening shell in X

[tetrahedra]

I have some custom additions to my $PATH. They're defined in ~/.profile 
and they are correctly loaded when I log in from a text console.


When I log in to X (cwm) and open a terminal window, $PATH does not 
contain the entries.


I tried `chmod +x` on my .profile but that didn't help.

Both the text console and the X terminal window are using ksh.

When I call `/bin/ksh -l` then the resulting shell contains the correct 
additions to $PATH.


It looks like the custom $PATH is not being passed from the login shell 
on downwards, since ~/.profile is only read by a login shell.


~/.kshrc is (according to ksh(1)) read by every spawning shell, but I 
don't see any documentation or examples on the Internet where someone 
defined their $PATH in ~/.kshrc ...


What's the correct way to set $PATH and have it stick no matter where 
and when the shell is spawned?

Re: Cultural underground legende Seymour Cray and his legacy

[tetrahedra]

On Thu, Apr 22, 2021 at 11:26:00AM -0600, jpeg bild wrote:

Your postings are the result of recent secret MKULTRA experiments.

good to know the cia runs pysops in mailinglists too
gangstalking is confirmed real


According to recently declassified CIA documents, most gangstalking 
perpetrators don't know they're doing it because they're being 
mind-controlled by the MKULTRA satellites. Now that you know, please 
stop gangstalking us.

Re: Trusted Boot with OpenBSD

[tetrahedra]

That's very interesting, and good work patching the assembly code.


On Wed, Apr 21, 2021 at 08:26:18AM +, podolica wrote:

Hi all,

I have tested if the trusted boot implementation
of Julius Zint for OpenBSD 6.5
(https://marc.info/?l=openbsd-misc=158255450604977=2)
is still working in OpenBSD 6.8.

Despite of some patch files that had to be updated,
all changes needed to be applied can be applied and
Trusted Boot can be used.
(Tested with an external hard drive and an amd64
ThinkPad with TPM module version 1.2)

Here are the new patch files. I did not provide them as
attachments because the netiquette says only the bugs,
ports and the tech mailing list are supporting
attachments although it was allowed when Julius Zint
made it's initial post. The files are beginning after
the ``` and are ending before the next ``` just like
in Markdown.


# gidt.S.patch
```
--- gidt.S.orig Mon Apr 19 13:22:32 2021
+++ gidt.S  Mon Apr 19 13:22:32 2021
@@ -432,11 +432,13 @@
movl%edi, _C_LABEL(BIOS_regs)+BIOSR_DI

/* clear NT flag in eflags */
-   pushf
+   push%eax
+   pushf
pop %eax
and $0xbfff, %eax
push%eax
popf
+   pop %eax

pop %gs
pop %fs

```

# cmd_i386.c.patch
```
--- cmd_i386.c.orig Mon Apr 19 13:23:44 2021
+++ cmd_i386.c  Mon Apr 19 13:23:44 2021
@@ -36,6 +36,7 @@
#include "biosdev.h"
#include "libsa.h"
#include 
+#include 

extern const char version[];

@@ -44,6 +45,7 @@
int Xdiskinfo(void);
int Xmemory(void);
int Xregs(void);
+int Xtpm(void);

/* From gidt.S */
int bootbuf(void *, int);
@@ -53,11 +55,155 @@
{ "comaddr",  CMDT_CMD, Xcomaddr },
{ "diskinfo", CMDT_CMD, Xdiskinfo },
{ "memory",   CMDT_CMD, Xmemory },
+{ "tpm",CMDT_CMD, Xtpm },
#ifdef DEBUG
{ "regs", CMDT_CMD, Xregs },
#endif
{ NULL, 0 }
};
+
+/**
+ * print_memory - debugging functionality to dump memory region to screen
+ * @buf:memory location to begin dump
+ * @rows:   rows to print
+ * @columns:columns to print
+ *
+ * Remarks: total bytes dumped = rows * columns
+ */
+void
+print_memory(void* buf, uint32_t rows, uint32_t columns)
+{
+uint8_t* iter = buf;
+for(int i = 0; i < rows; i++) {
+printf("%03x:", i * columns);
+for(int k = 0; k < columns; k++) {
+printf(" %02x", *iter);
+iter++;
+}
+printf("\n");
+}
+}
+
+#define SECRET_BLK_OFF 1
+
+int
+Xtpm(void)
+{
+int rc;
+uint8_t major = 0;
+uint8_t minor = 0;
+rc = tpm_statuscheck(, );
+   if(rc != 0) {
+printf("No TCG compliant BIOS available.\n");
+   }
+   else if(major != 1 && minor != 2) {
+printf("Incompatible TCG BIOS version: %u.%u\n", major, minor);
+   }
+   if (cmd.argc < 2) {
+printf("machine tpm r[andom]|p[cr]|u[nseal] [DiskNumber]|s[eal] 
secret [DiskNumber]\n");
+printf("strlen(secret) <= 100\n");
+return 0;
+}
+switch(cmd.argv[1][0]) {
+case 'r': {
+char random_buf[20];
+tpm_random(random_buf, 20);
+print_memory(random_buf, 2, 10);
+} break;
+case 'p': {
+tpm_printpcr(0, 15);
+} break;
+case 'u': {
+// load secret disk block
+int disk_number = 0x80;
+if(cmd.argc == 3) {
+disk_number = (int)strtol(cmd.argv[2], NULL, 0);
+}
+unsigned char* secret_disk_block = alloc(512);
+memset(secret_disk_block, 0x00, 512);
+struct diskinfo * disk_info = dklookup(disk_number);
+if(disk_info == NULL) {
+printf("IO Error - Disk %x not found\n", disk_number);
+goto unseal_end;
+}
+rc = biosd_diskio(F_READ, disk_info, SECRET_BLK_OFF, 1, 
secret_disk_block);
+if(rc != 0) {
+printf("IO Error \n");
+goto unseal_end;
+}
+if (secret_disk_block[0] != 'A' ||
+secret_disk_block[1] != 'E' ||
+secret_disk_block[2] != 'M' ||
+secret_disk_block[3] != 'S')
+{
+printf("No sealed secret found on disk");
+goto unseal_end;
+}
+uint32_t sealed_size = *((uint32_t*)(secret_disk_block + 4));
+unsigned char* sealed_data = secret_disk_block + 8;
+if(sealed_size > 512) {
+printf("Invalid size for sealed data\n");
+goto unseal_end;
+}
+
+// 

Re: TouchPad, right clicking, and cwm

[tetrahedra]

On Sun, Apr 18, 2021 at 11:09:00PM +0200, Ulf Brosziewski wrote:

They are using them.  Which problems do you expect?  The "ClickFinger"
mechanism is the only feature of synaptics(4) that doesn't work properly
because MT data are missing.  Users that prefer synaptics(4) to wsmouse(4)
will turn the "ClickPad" option on, activate "soft-buttons" or tapping, and
that's it.


Okay, so it sounds like the recommended solution is to use either:
a. synaptics(4) with ClickPad and soft-buttons or tapping, or
b. use wsmouse(4)

Did I understand that right? How do people produce right- or 
middle-clicks with a) and tapping? (for trackpads that have no defined 
soft-button areas)


And to configure b), I assume that's just another set of xorg.conf 
configuration lines? or is there additional complexity I'm missing?



As to the default driver in wsmouse(4), it doesn't require any manual
configuration for clickpads, if you you are happy with soft-buttons (tapping
can be enabled).


That sounds good. But unlike some laptops, my clickpad doesn't have any 
defined soft-button areas. Maybe there is a way to define them?

Re: TouchPad, right clicking, and cwm

[tetrahedra]

On Fri, Apr 16, 2021 at 08:56:59PM +0200, Ulf Brosziewski wrote:

Unfortunately, that "trick" is no general solution because turning the
"ClickPad" option off makes click-and-drag operations with two fingers
impossible.  If you don't use that "gesture", or perform it with one
finger only, the setup might work for you.

I think the issue won't be fixed, for various reasons:  synaptics(4) is
legacy, there is no active development.  It cannot handle that setup
coherently because a reasonable treatment of the "ClickFinger" method
requires full multitouch data.  Only a subset of our hardware drivers
provide MT support, and even if these data are available, they aren't
passed to userland drivers in OpenBSD.  Only wsmouse(4) makes use of
them, but it doesn't offer that "click method" for touchpads - hardly
anyone has asked for it.


I see. So how do people deal with newer generation touchpads that don't 
have buttons?

Re: TouchPad, right clicking, and cwm

[tetrahedra]

On Fri, Apr 16, 2021 at 12:08:56AM +0200, Ulf Brosziewski wrote:

Could you remove the "ClickPad" option from the configuration file and
try two-finger clicks again?

The combination of that option with the "ClickFinger" mechanism is broken,
and you probably don't need it if you don't use "soft-button areas".


Thanks! That did the trick.

Three-finger clicks should work - if your hardware detects the number 
of

fingers reliably.


Unfortunately, it doesn't, and right-clicking is more important than 
middle-clicking, so now my file looks like:


Section "InputClass"
Identifier "touchpad"
Driver "synaptics"
MatchIsTouchpad "on"
Option "VertEdgeScroll" "off"
Option "VertTwoFingerScroll" "on"
Option "ClickFinger2" "3"
Option "ClickFinger3" "2"
EndSection

If it's not practical to fix the bug with the "ClickPad" option, I would 
suggest adding a note to the synaptics(4) manpage under "ClickPad 
support", perhaps something along the lines of:


The use of the option ClickPad in combination with Option ClickFinger2 
and/or ClickFinger3 is currently not fully supported and may lead to 
unexpected behaviour. In particular, enabling the Option ClickPad may 
cause ClickFinger functionality to stop working.

TouchPad, right clicking, and cwm

[tetrahedra]

Hi,
I'm trying to get my TouchPad/trackpad to right click. I put the 
following in my /etc/X11/xorg.conf.d/70-synaptics.conf:


Section "InputClass"
Identifier "touchpad"
Driver "synaptics"
MatchIsTouchpad "on"
Option "ClickPad" "on"
Option "VertEdgeScroll" "off"
Option "VertTwoFingerScroll" "on"
Option "ClickFinger2" "2"
Option "ClickFinger3" "3"
EndSection

However, this was not enough to get two- or three-finger clicking 
working.


I'd even be satisfied with Ctrl-Click mapping to right-click.

Has anyone got any ideas how to make either option work?

Auto-mounting removable disks

[tetrahedra]

I have a removable disk that I want to auto-mount. However, it may not 
always be present. If I put an entry in fstab for it, will the system be 
able to cope even if the disk is not present?


Is there a better way to do this?

Re: Keeping xlock on top in cwm

[tetrahedra]

On Thu, Mar 18, 2021 at 06:53:31AM +0100, Robert Klein wrote:

Thanks, but I like having xconsole... is there any way to make it
obey the gap?



I start xconsole in Xsetup_0 as follows

xconsole -geometry 480x130-0-26 \
   -daemon \
   -notify \
   -verbose \
   -exitOnFail

The gap in my case is the 26.  -26 means 26 pixel from the bottom.


Thanks! Set the gap to be equal to my .cwmrc gap, and xclock is now 
nicely visible all the time. No more being late ever again :)

Re: Keeping xlock on top in cwm

[tetrahedra]

On Tue, Mar 16, 2021 at 04:53:32PM -0400, Dave Voutila wrote:

I worked out how to set a "gap" so that maximized windows won't
obscure the xclock line at the bottom. That helped. Unfortunately,
it's not enough. By default `xconsole` is sized and positioned so, if
brought forward, `xconsole` obscures `xclock`. That invariably happens
if cycling through windows...


You can change or remove xconsole from starting by modifying
/etc/X11/xenodm/Xsetup_0


Thanks, but I like having xconsole... is there any way to make it obey 
the gap?

Re: Keeping xlock on top in cwm

[tetrahedra]

On Tue, Mar 16, 2021 at 06:11:09PM +, tetrahe...@danwin1210.me wrote:
In cwm, is there a way to keep a particular 
window (in this case, xclock) "always on top"?


I don't see anything in the man page, but maybe I missed something:
https://man.openbsd.org/cwmrc


I worked out how to set a "gap" so that maximized windows won't obscure 
the xclock line at the bottom. That helped. Unfortunately, it's not 
enough. By default `xconsole` is sized and positioned so, if brought 
forward, `xconsole` obscures `xclock`. That invariably happens if 
cycling through windows...

Keeping xlock on top in cwm

[tetrahedra]

In cwm, is there a way to keep a particular window (in this case, 
xclock) "always on top"?


I don't see anything in the man page, but maybe I missed something:
https://man.openbsd.org/cwmrc

Re: Default partitions allocate only 1GB to /

[tetrahedra]

On Sun, Feb 28, 2021 at 08:30:14PM +0100, Janne Johansson wrote:

Is /var a filesystem of its own? Otherwise it could be /var/tmp or
some other place under /var which is used for unpacking packages.


Yes, /var is on its own filesystem, with 10.4G available.

Re: Default partitions allocate only 1GB to /

[tetrahedra]

On Sun, Feb 28, 2021 at 05:17:15PM +, James Cook wrote:

> This makes little sense to me. Why should deleting a 20MB file on a
> filesystem with >700MB free space be sufficient for the install to go
> through? Especially when the install obviously doesn't need that much space
> on the filesystem in question?

That doesn't make sense to me either. Something strange is going on.
Maybe someone else will have a guess.


It did occur to me that between the first (unsuccessful) and 2nd 
(successful) attempts I also rebooted the machine and ran `pkg_add -u`.

Re: Default partitions allocate only 1GB to /

[tetrahedra]

On Sat, Feb 27, 2021 at 11:52:39PM +, James Cook wrote:


Sorry, you're right, pkg_add can add files to /. But generally those
will be quite small (/etc/make2fs.conf sounds like a configuration
file).

How big is your root partition, and how much space is used? For example
mine is like this after several months of use and many packages
installed, indicating the installer's default behaviour has worked well
for me:


falsifian angel ~ $ df -h /
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd2a  989M199M741M21%/


My root partition is about the same -- circa 1GB in size, about 700MB 
free.


According to `df -h` my /user/local has 11.4GB available and /usr has 
3.5GB, so there *should* be plenty of space for Libreoffice.

Re: Default partitions allocate only 1GB to /

[tetrahedra]

On Sat, Feb 27, 2021 at 11:52:39PM +, James Cook wrote:

If you have a lot more space used, you could try to figure out what's
using it. My go-to command is "du -xah /|sort -h|less"


That's a neat command, and amazingly enough it did the trick: there was 
a 20MB file, INS@yjf(...) located in the root directory. It looked like 
a copy of the kernel binary which had been saved while I was messing 
about with kernel configuration options.


I deleted the file and `pkg_add libreoffice` worked as expected.

Post-install I still have 746MB free in /, according to `df -h`.

This makes little sense to me. Why should deleting a 20MB file on a 
filesystem with >700MB free space be sufficient for the install to go 
through? Especially when the install obviously doesn't need that much 
space on the filesystem in question?


(space available in /usr/local went from 11.4G, pre-install, to 10.8G, 
post-install... was `pkg_add` trying to stage files in /, even though 
/tmp is a separate filesystem?)

Re: Default partitions allocate only 1GB to /

[tetrahedra]

On Sat, Feb 27, 2021 at 03:27:41PM -0600, Edgar Pettijohn wrote:
Its more likely that you accidentaly used dd to write to a usb stick 
and instead

wrote to a file in /dev.  Thats the only way I've ever had this
problem.


You're right -- I had written a file to /dev. After deleting it, the 
problem still comes up, unfortunately.

Re: Default partitions allocate only 1GB to /

[tetrahedra]

On Sat, Feb 27, 2021 at 08:27:07PM +, James Cook wrote:

Something's strange about your setup. The installer normally creates a
separate partition for /usr and maybe /usr/local. If you're using
pkg_add, then packages go in /usr/local, so they shouldn't end up on
your root partition.

If your disk is really tiny the installer won't create a separate /usr
partition, but in that case it won't make a separate /home either.


As far as I know everything was installed using defaults.

Doing `pkg_add libreoffice` the installer is definitely looking at both 
/ and /usr/local/ ... and it gives an odd bytecount for /:


```
Error: /dev/sda1 on / is not large enough (/etc/mke2fs.conf)
/dev/sda1 on /: 956 bytes (missing 86470 blocks)
/dev/sd1h on /usr/local: 4513435 bytes
```

Later it gives different byte counts for both values.

Default partitions allocate only 1GB to /

[tetrahedra]

When installing OpenBSD, the default partition layout only allocates 1GB 
to / ... most of the disk space is allocated to /home.


Once you start installing packages, / quickly grows beyond 1GB, and it 
looks like even some large packages exceed the available space on their 
own:

Error: /dev/sda1 on / is not large enough

Is there an easy fix for this that I'm missing somewhere, or is this a 
poorly chosen default?

Re: Bootloader on USB stick fails with "root device not found"

[tetrahedra]

On Sun, Jan 31, 2021 at 12:06:37PM +0100, Stefan Sperling wrote:

On Sun, Jan 31, 2021 at 11:47:04AM +0100, Stefan Sperling wrote:

In general, crypto softraid volumes don't auto-assemble.


I forgot that softraid volumes that use a key disk instead of a
passphrase will auto-assemble. Have you already tried that?
A disklabel slice on the USB key could act as a key disk for
the encrypted volume on the internal disk.


I am looking at the manpage for bioctl(8) and I don't see any provision 
for either changing the passphrase of an existing encrypted disk, or 
replacing the passphrase with a keydisk.


Is there any way to change my existing install over to using a keydisk, 
instead of a passphrase? Or do I need to wipe everything and re-install?

Re: Bootloader on USB stick fails with "root device not found"

[tetrahedra]

On Wed, Feb 10, 2021 at 03:59:12PM +0100, Stefan Sperling wrote:

On Wed, Feb 10, 2021 at 01:00:33PM +, Frank Beuth wrote:

On Tue, Feb 02, 2021 at 10:50:39PM +0100, Stefan Sperling wrote:
> The idea of protecting key disks with a passphrase (two-factor auth) has
> been raised before. It has not been implemented yet, simply because nobody
> has done the work. A search of the mailing list archives should yield
> some prior discussion.

How about backup keys, so I can have a backup passphrase stored somewhere
safely that works even if I lose my keydisk?


Well, even if two-factor auth were already available, if you lose
the key disk then you should also lose access to the encrypted data.
Otherwise it's not two-factor auth. A scheme where either a passphrase
or a key disk could be used to unlock the volume would be redundant and
even dangerously confusing for users who expect actual two-factor auth.


My original question was about letting the user define behaviour between 
multiple keys.


For example, having X number of key-slots representing 
passphrases/keyfiles/Yubikeys/etc, and the user can define whether they 
are AND (all needed to unlock) or OR (any one needed to unlock).


I suppose the theoretical ideal here would be a key-management 
programming language (a derivative of LISP?) to express the desired 
relationships ("unlock if ANY of these three keys, or ALL of these two, 
or two from the first group and one from the 2nd") but given the human 
inability to write bug-free code maybe that's a bad idea.

Re: Bootloader on USB stick fails with "root device not found"

[tetrahedra]

On Sun, Jan 31, 2021 at 12:06:37PM +0100, Stefan Sperling wrote:

On Sun, Jan 31, 2021 at 11:47:04AM +0100, Stefan Sperling wrote:

In general, crypto softraid volumes don't auto-assemble.


I forgot that softraid volumes that use a key disk instead of a
passphrase will auto-assemble. Have you already tried that?
A disklabel slice on the USB key could act as a key disk for
the encrypted volume on the internal disk.


Thanks, that's a very interesting idea, I will try that and let you 
know.


Looking thru the manpages, I don't see any provision for adding AND / OR 
logic to keys (e.g require both passphrase AND keydisk to boot, require 
passphrase OR keydisk, etc) the way Linux cryptsetup provides, at least, 
OR-logic across multiple keyslots.


(Having multiple keyslots on an encrypted volume has saved me a few 
times!)


Is there anything like this in OpenBSD?

Re: Bootloader on USB stick fails with "root device not found"

[tetrahedra]

On Fri, Jan 29, 2021 at 12:46:50PM +, tetrahe...@danwin1210.me wrote:
- when booting from the bootloader on the internal HD, and after   
decrypting the encrypted volume, the system is able to find the disk   
e8 without trouble, but


- when booting from the bootloader on the USB stick, and after   
decrypting the same encrypted volume (with the same password, etc),   
the system is NOT able to find the disk e8.


What the heck is going on? Why can't the system find softraid volume 
that it just decrypted?


Still haven't been able to find a solution to this. The boot, softraid, 
installboot manpages (as far as I can tell) offer no answers.


Does anyone here understand how the kernel looks for available volumes 
during the boot sequence?


Why would the kernel, when booted from a bootloader on one physical 
disk, be able to find a root device -- but, when booted from a 
bootloader on a different physical disk, not be able to do so? (even 
when the bootloaders in both cases decrypted the correct disk)

Re: Bootloader on USB stick fails with "root device not found"

[tetrahedra]

On Tue, Jan 26, 2021 at 03:41:23PM +, tetrahe...@danwin1210.me wrote:

Any ideas why the kernel isn't seeing sr0a as a root device?


As suggested in the "Managed to mess up the system encrypted disk. I can 
no longer boot" thread, I tried running installboot from the working 
(booted from the internal disk bootloader) system against all the 
relevant disks:
- the USB drive 
- sd0 (the physical disk, with the bootloader)

- sd1 (aka sr0 or softraid0, the now-decrypted encrypted volume)

Unfortunately this did not fix the problem, I am still geting kernel 
panics.


Looking more closely at the error message:
panic: root device (e8) not found

the code given (e8) is the disklabel disk ID of the root volume (sd1 
/ softraid0) as given in /etc/fstab (when the system is booted from the 
internal bootloader). It's the ID of the (decrypted) softraid volume.


Therefore:

- when booting from the bootloader on the internal HD, and after 
  decrypting the encrypted volume, the system is able to find the disk 
  e8 without trouble, but


- when booting from the bootloader on the USB stick, and after 
  decrypting the same encrypted volume (with the same password, etc), 
  the system is NOT able to find the disk e8.


What the heck is going on? Why can't the system find softraid volume 
that it just decrypted?

Re: Managed to mess up the system encrypted disk. I can no longer boot.

[tetrahedra]

On Thu, Jan 28, 2021 at 10:27:47AM +0200, Samarul Meu wrote:

Thank you so much! You made my day!
So I used FuguIta (6.8 - stable) attached the encrypted partition
(accessible as sd1 now) and 'installboot sd1', reboot and surprise -
everything is working. I still have no idea why detaching the softraid
determined this kind of behavior.

Best regards,
Samarul

P.S. To tetrahedra --- maybe this solution will solve your problem also.


Unfortunately not... I will explain what I tried over in that thread.

Re: Can't set 'from' address in .mailrc

[tetrahedra]

On Thu, Jan 28, 2021 at 09:51:57PM +, Stuart Henderson wrote:

Not 100% sure but I think you can just edit it in the template file.
But unless you've got a properly configured mail setup on the machine
saving it as a text file is probably easier.


Editing it in the template file did the trick. Thanks!

Re: Can't set 'from' address in .mailrc

[tetrahedra]

On Thu, Jan 28, 2021 at 05:30:47PM +0100, Marcus MERIGHI wrote:

2. Where can I find the message that 'sendbug' composed? 'ls
/var/spool/smtpd/queue/*' does not show any messages in any of the
subfolders, did smtpd delete it because it couldn't be delivered?


Do you see

smtpd[30872]: warn: queue: no return path!

in /var/log/maillog? Do you have a file named "dead.letter"?


'doas find / -iname dead.letter' produces no results.

there is nothing matching "no return path" in /var/log/maillog.

Re: Can't set 'from' address in .mailrc

[tetrahedra]

On Thu, Jan 28, 2021 at 05:30:07PM -, Stuart Henderson wrote:

You could use "sendbug -P > sendbug.out" to get your report in a file
and send that from a different host. Or edit the file and

$ cat sendbug.out | mail -s "my bug report" -r my_lap...@domain.com \
-c my_lap...@domain.com b...@openbsd.org


unless you do this, sendbug doesn't use mail(1), it uses /usr/sbin/sendmail
directly.


Okay, how do I specify that sendbug sets a specific from address when 
sending mail? Or do I have to save it as a text file as discussed above

Can't set 'from' address in .mailrc

[tetrahedra]

I'm trying to set up my system so I can use 'sendbug' to send in a bug 
report for a kernel panic, and a number of issues have cropped up.


1. My mail provider won't let me send email from  but 
only from . Therefore I tried adding to ~/.mailrc:

set from "my_lap...@domain.com"
Unfortunately, this didn't fix the issue, and /var/log/maillog is still 
showing "Sender address rejected" messages.


According to the mail manpage 'from' is a binary option, but this makes 
no sense to me, where does one set the default from address?


2. Where can I find the message that 'sendbug' composed? 'ls 
/var/spool/smtpd/queue/*' does not show any messages in any of the 
subfolders, did smtpd delete it because it couldn't be delivered?

Re: Managed to mess up the system encrypted disk. I can no longer boot.

[tetrahedra]

On Wed, Jan 27, 2021 at 05:50:07PM +0200, Samarul Meu wrote:
After searching online I discovered this: boot sr0a:/bsd. Now it asks 
for

my Passphrase and it starts booting but then it hangs

softraid0 at root
scsibus2 at softraid0: 256 targets
panic: root device (3312a...) not found
Stopped at db_enter+0x10: popq %rbp
TID  PID UID PRFLAGS PFLAGS CPU COMMAND
* 00  0  0x1 0x2000  0kswapper
panic(ff81dff) at panic+0x12a
setroot(80..) at setroot+0xdeb
disconf(1b21..) at diskconf+0x185
main(0,0,0,0,0,80..) at main+0x500
end trace frame: 0x0, count:10https://www.openbsd.org/ddb.html
describes the minimum info required inbug reports. Insufficient
info makes it difficult to find and fix bugs.
ddb{0}>

Using a usb drive with *FuguIta* I managed to do a fsck on all partitions
(some errors appeared, but I cleaned them).

I was even able to mount them and everything seems fine, I recovered what I
was working on, but I have no luck in booting. Again and again the above
error.


Ironically this is the same error I have been getting, and recently 
posted about in the thread "Bootloader on USB stick fails with "root 
device not found"" ...

Re: cwm manpage default keybinding is incorrect

[tetrahedra]

On Tue, Jan 26, 2021 at 12:06:43PM -0500, Okan Demirmen wrote:
Please see my 2nd post where I explained I was hitting "Backspace", 
and the

official documentation does not mention any binding for CM-Backspace.


I did not see a 2nd post; in any case, this is not cwm(1), rather the
default mapping to terminate X and documented in default xkb mappings.



Okay, then that would explain it. Thanks!

Re: cwm manpage default keybinding is incorrect

[tetrahedra]

On Tue, Jan 26, 2021 at 09:39:31AM -0500, Okan Demirmen wrote:

On Sat 2021.01.23 at 01:04 +, tetrahe...@danwin1210.me wrote:

The cwm default keybindings listed in the manpage do not appear to be
entirely correct:
https://man.openbsd.org/cwm

For example the man page lists:
CM-DeleteLock the screen.

However, CM-Delete actually restarts the window manager (!) on my install
(6.8).


Hi - Are you sure you're hitting 'Delete' and not 'Backspace'? Or have
re-mapped keys?


Please see my 2nd post where I explained I was hitting "Backspace", and 
the official documentation does not mention any binding for 
CM-Backspace.

Re: Bootloader on USB stick fails with "root device not found"

[tetrahedra]

On Mon, Jan 25, 2021 at 08:08:20PM +0100, Jan Stary wrote:

I am trying to set up the bootloader on an external
USB stick to boot my FDE-encrypted disk:


Why? You say you can boot from the disk itself.


See the original linked email discussion from my post for the reasons 
why. Short answer: if you have your bootloader with you at all times in 
your pocket, an evil maid can't tamper with it to recover your FDE 
encryption key.


I managed to get the thing not to panic by using 
the -a flag, i.e

boot> boot sr0a:/bsd -a

Unfortunately, when I use the kernel-suggested default devices (root 
device on sd1a, swap device sd1b) then I boot the OS on my USB stick, 
rather than the OS on the FDE encrypted drive.


If I tell it to boot sd0a (root) / sd0a (swap) then it panicks with 
"cannot mount root". (probably because sd0 is an encrypted drive)


If I type ? then it gives me the options:
exit em0 sd0[a-p] sd1[a-p]

If I try telling it to boot sr0a as the root device, then it again just 
prompts me with the available options given above -- evidently it can't 
find sr0a.


It looks to me like -- even though it is prompting me for the FDE 
encryption password after I enter the 'boot sr0a:/bsd -a' command -- the 
kernel is ether not decrypting or not mounting the softraid disk.


Booting with the '-c' option and typing 'list' shows that there is a 
softraid entry:

6 softraid0 at root flags 0x0

Attempting to enable it with 'enable 6' returns the message
6 softraid0 already enabled

The kernel does not accept 'softraid0a' as a root device name.

'machine diskinfo' at the boot> prompt reveals that the hard disk is hd1 
and the USB stick is hd0. However, the post-probe list of available 
disks is

hd0 hd1 sr0*
so I assume there is no point to trying to boot sr1a.

Any ideas why the kernel isn't seeing sr0a as a root device?

Re: FDE disk setup instructions are misleading when installing from USB

[tetrahedra]

On Sat, Jan 23, 2021 at 04:25:39PM -0800, Bryan Wright wrote:

Perhaps someone will make some changes to the installer or documentation. But, 
I can tell you, a diff,  or at least a proposed specific solution, will always 
go a lot further than pointing out a potential problem, simply because there 
are relatively few developers and they all have things they are busy with.


It's hard for me to propose a solution since I don't know the situation. 
However, the solution I originally had in mind was the solution that 
someone else proposed already:


add language to the FDE section of the FAQ explaining how to verify 
which drive is which, before overwriting the first 1M of that drive with 
zeroes.


The other solution which was proposed (update the installer to support 
FDE, since everyone does it these days) is also great.

Bootloader on USB stick fails with "root device not found"

[tetrahedra]

As per this discussion I am trying to set up the bootloader on an 
external USB stick to boot my FDE-encrypted disk:

https://marc.info/?l=openbsd-misc=158196161321272=2

When booting from the USB stick (which contains a full install), I 
follow the softraid.4 man page example and do:

boot> boot sr0a:/bsd

When booting, the boot stops immediately after "scsibus4 at softraid0: 
256 targets" with the error message "panic: root device (..) not found"


If I boot from the standard bootloader on the FDE encrypted disk itself, 
everything boots fine.


Has something changed since the earlier discussion, is it no longer 
possible to use a USB stick to boot an encrypted partition?

Re: FDE disk setup instructions are misleading when installing from USB

[tetrahedra]

On Fri, Jan 22, 2021 at 04:44:31PM -0800, Bryan Wright wrote:




but to set up FDE I had to reference the official FAQ


Referring to the official documentation is a key distinction between successful 
OpenBSD use and that of many other systems; the early that gets hammered home 
the better, right?  It’s practically unGoogleable, if that’s a word.

It can be super frustrating at times, but half blindly following a 
guide or entering some unexplained command from Stackoverflow, while 
being much easier, has got to be among the most dangerous patterns we 
can adopt.  Using OpenBSD has been a very humbling experience, but I’ve 
learned so, so much by being forced to adopt better practices.


For the record, I started by reading the FAQ from start to finish, 
before I installed anything.


Unfortunately it's a little difficult to connect to reality (or even 
remember) much of what one reads when one does this.


"Does this obscure technical reference apply to my situation? I don't 
know, I haven't worked with anything related to it yet!"


To make matters worse, there are an awful lot of details that are not 
realistic to get out of the official documentation... I would have had 
to read a significant percentage of all the manpages, and a lot of 
mailing list traffic, in order to arrive at the same steps provided in 
how-tos like .


Could I have done that? Sure. Would spending 40-80 hours reading 
documentation just to get a laptop set up, when I don't know whether I'm 
going to use it for more than experimental purposes, have been a good 
use of my time? Certainly not.


I have no quarrel with OpenBSD requiring new users to immediately dive 
into parts of the system that other operating systems try as hard as 
possible to hide... but for practical reasons it does seem necessary to 
do a little hand-holding along the way.


I am therefore extremely grateful to Cullum Smith and the other "OpenBSD 
on a laptop" howtos for making it feasible to get this far.

cwm manpage default keybinding is incorrect

[tetrahedra]

The cwm default keybindings listed in the manpage do not appear to be 
entirely correct:

https://man.openbsd.org/cwm

For example the man page lists:
CM-DeleteLock the screen.

However, CM-Delete actually restarts the window manager (!) on my 
install (6.8).

Re: FDE disk setup instructions are misleading when installing from USB

[tetrahedra]

On Fri, Jan 22, 2021 at 02:39:25PM -0800, Bryan Wright wrote:

Because, there is no guarantee that the drives will be loaded in a given order 
on boot, there would be little benefit in changing the example.  If the entire 
page is read, everything should be clear enough, but if anything were to be 
done, perhaps there could be a reminder within each subsection to verify the 
disk with ‘sysctl hw.disknames’ and ‘disklabel’.


Having a reminder to verify disks is the fix I had in mind. 

Unfortunately there are a lot of slightly out of date guides to setting 
up OpenBSD on a laptop out there. They are extremely valuable but to set 
up FDE I had to reference the official FAQ, due to subtle changes since 
the older guides were written.


The section of the FAQ on FDE therefore seems likely to be read by 
people who are not starting at the top of the page and reading the whole 
thing.

FDE disk setup instructions are misleading when installing from USB

[tetrahedra]

When installing from a USB thumb drive, the machine's internal HDD 
usually shows up as sd0 and the thumb drive as sd1.


However, the FDE installation instructions 
 suggest that we 
should overwite the first 1MB of sd1 with zeros:



# dd if=/dev/zero of=/dev/rsd1c bs=1m count=1


If the user is installing from a USB drive, this will lead to them 
overwriting the USB drive, rather than the pseudo-device.

Re: Integrating OpenBSD into Xen/Qubes

[tetrahedra]

On Fri, Oct 16, 2020 at 11:35:40AM +0200, Anders Andersson wrote:

How could any hardening in OpenBSD protect from someone owning the
hardware? Or do you mean that an OpenBSD guest would run with
exclusive access to the NIC and then every other guest is routed
through that guest?


Yes, exactly. The OpenBSD guest would have exclusive access to the NIC, 
and handles all networking for the entire system.


At the moment, Qubes uses a Fedora Linux-based guest system to handle 
networking. This means that if an attacker can compromise the Fedora 
networking drivers, they can compromise the guest, and potentially use 
the guest's PCI access to exploit Xen.


As noted in the original Github issue, attacks on networking sub-systems 
are all too common (apparently some Middle Eastern countries are 
building or have built systems to mass exploit anyone who e.g connects 
to a shopping mall's Wi-Fi network).


OpenBSD's hardening and generally higher standard of code quality would 
go a long way to mitigating this attack scenario.

Integrating OpenBSD into Xen/Qubes

[tetrahedra]

A number of people are working on integrating OpenBSD into Qubes.

In particular, OpenBSD's hardening and mitigations are potentially very 
useful in talking to the NIC: Xen vulnerabilities have been repeatedly 
found that would allow a guest with PCI access to compromise the entire 
system, and on most machines the network card is a PCI device. 

Additionally, wireless drivers on Linux leave some things to be desired 
and the network stack is very exposed to the adversary compared to other 
aspects of the system.


The limited scope of the networking VM in Qubes (it does not need much 
in the way of bells and whistles, it simply talks to the NIC and passes 
on data) means that it's much easier to use OpenBSD here than it would 
be to use OpenBSD for e.g GUI applications.


Unfortunately, there are still significant issues (currently good 
integration requires patching /etc/rc, among other things):

https://github.com/QubesOS/qubes-issues/issues/5294#issuecomment-707278609

As the commenter notes, this would be much easier if an OpenBSD 
committer was interested in helping. Anyone?