Re: Web based document / spredsheet editor

[Demi M. Obenour]

On 2020-09-22 15:07, Ottavio Caruso wrote:
> On 22/09/2020 14:37, Martin Sukany wrote:
>> Hi colleges,
>>
>> I need to set up some kind of collaborative environment (rich text 
>> docjuments, basic tables) — request is „something like google docs“.
>>
>> As I’m almost working in shell I have to say that I’m little bit lost in 
>> this area.
>>
>> Could you recommend me some web-based application (idealy something which is 
>> „easily“ deployed on OpenBSD)? If it wouldn’t have behind some of the ‚big 
>> frameworks‘, it would be great.
> 
> Whichever web based "like Google docs" solution will require the 
> latest/greatest version of Chrome/Firefox and probably will work 100% fine 
> only on Windows/ChromeOS.

Firefox and Chromium both work on OpenBSD, too.

Demi

Re: Web based document / spredsheet editor

[Ottavio Caruso]

On 22/09/2020 14:37, Martin Sukany wrote:

Hi colleges,

I need to set up some kind of collaborative environment (rich text docjuments, 
basic tables) — request is „something like google docs“.

As I’m almost working in shell I have to say that I’m little bit lost in this 
area.

Could you recommend me some web-based application (idealy something which is 
„easily“ deployed on OpenBSD)? If it wouldn’t have behind some of the ‚big 
frameworks‘, it would be great.


Whichever web based "like Google docs" solution will require the 
latest/greatest version of Chrome/Firefox and probably will work 100% 
fine only on Windows/ChromeOS.


Libreoffice is not web based but can work on remote repositories:
https://help.libreoffice.org/6.3/en-US/text/shared/guide/cmis-remote-files-setup.html


--
Ottavio Caruso

Re: Web based document / spredsheet editor

[Uwe Werler]

On 22 Sep 15:37, Martin Sukany wrote:
> Hi colleges,
> 
> I need to set up some kind of collaborative environment (rich text 
> docjuments, basic tables) — request is „something like google docs“. 
> 
> As I’m almost working in shell I have to say that I’m little bit lost in this 
> area.
> 
> Could you recommend me some web-based application (idealy something which is 
> „easily“ deployed on OpenBSD)? If it wouldn’t have behind some of the ‚big 
> frameworks‘, it would be great.
> 
> Any hints welcomed … 
> 
> Thanks
> M>
> 
> 
> S pozdravem / Kind regards
> 
> Martin Sukaný
> UNIX Engineer, Developer, DevOps specialist
> xmpp: mar...@sukany.cz
> phone: +420 776 275 713
> email: mar...@sukany.cz
> l: https://www.linkedin.com/in/martins6
> 
> 
> 

Hi Martin,

we have at work nextcloud plus collabora online dev edition. Works so far. The
latter one I used the container from them - it's debian based - and run it on
kvm.

-- 
wq: ~uw

Re: Web based document / spredsheet editor

[Martin Sukaný]

Hi Ben

So far I know troff is just the command line-based tool   I would need 
something which is available through the web browser as well for the end users. 



Odesláno z iPhonu

> 22. 9. 2020 v 17:34, ben :
> 
> Troff.
> 
> 
> Ben Raskin.

Web based document / spredsheet editor

[Martin Sukany]

Hi colleges,

I need to set up some kind of collaborative environment (rich text docjuments, 
basic tables) — request is „something like google docs“. 

As I’m almost working in shell I have to say that I’m little bit lost in this 
area.

Could you recommend me some web-based application (idealy something which is 
„easily“ deployed on OpenBSD)? If it wouldn’t have behind some of the ‚big 
frameworks‘, it would be great.

Any hints welcomed … 

Thanks
M>


S pozdravem / Kind regards

Martin Sukaný
UNIX Engineer, Developer, DevOps specialist
xmpp: mar...@sukany.cz
phone: +420 776 275 713
email: mar...@sukany.cz
l: https://www.linkedin.com/in/martins6

Re: Web based document / spredsheet editor

[ben]

You could host a repository on Github or other Git provider and edit troff 
documents that way (as Git will very easily track changes in basic text files).


Ben Raskin.

Re: Web based document / spredsheet editor

[ben]

Troff.


Ben Raskin.

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Theo de Raadt]

>In my use-case, the program’s correct functionality is less
>important than ensuring that the program cannot break out.

Astounding.  It's like you don't see correct execution environment for
a program as THE foundational aspect of security; while at the same
time this rests on the assuption that unveil and pledge are correct
code.  So some stuff has to be correct, but other stuff doesn't, and
then the handwaving begins.

I'm done talking about this.

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Demi M. Obenour]

On 2020-09-22 10:58, Theo de Raadt wrote:
>> I actually agree with this.  Designing a program with pledge in
>> mind is always better.  However, that requires that the program be
>> trusted, and there still may be some corner cases in which I can
>> tighten down the pledge more than the program itself can.
> 
> I disagree. I don't believe you can correctly produce security, because
> the pledge operation puts the program into an unexpected non-POSIX
> operational environment, and will introduce new potential error conditions
> the program does not expect.

In my use-case, the program’s correct functionality is less
important than ensuring that the program cannot break out.

>> So I can sandbox ftp(1) more than ftp(1) can reasonably sandbox itself.
> 
> I very strongly disagree.  At best the pledge/unveil-wrapper will work in
> a specific one-time configuration, and not be generalizable.

Indeed it is not generalizable.

> We do not want users to be experimenting with things they don't understand,
> more precisely, things they cannot understand because this high-level pledge
> command is changing big underlying conditions.
> 
>> To be fair, one could argue that ftp(1) should have a command-line
>> option that enables these lockdown options and disables the features
>> unsupported under this mode.
> 
> Disagree.  This is not supposed to be user visible.

That’s why I posted the lockdown patch to remove the exec pledge
when it isn’t required.

>> That isn't actually not the main use case for pledge(1),
>> at least for me.  The main use-case is to sandbox untrusted,
>> potentially malicious executables.
> 
> That is propostrous.
> 
> You think it's a good idea to throw untrusted programs into an
> environment they were not designed...

Personally, I would prefer to run something like
https://play.rust-lang.org under the hardened OpenBSD kernel than
under Linux.  However, without a way to sandbox these binaries,
it can't be done.

>> I do not know any way to
>> implement something like the Rust Playground securely on OpenBSD
>> without using execpromises, at least without requiring at least part
>> of the application to run as root.  With execpromises, sandboxing
>> untrusted executables is trivial.  That's what pledge(1) is for.
> 
> No it is not trivial!  You are running code in *NON-POSIX MODES*.

I know.  In my use-case, POSIX conformance is not necessary.
Rust works just fine on Windows, for example.

>> In my main use-case, I know what pledges I am willing to allow
>> untrusted code to have.  If it tries to do something that the
>> sandbox doesn't allow, it *should* fail.  I expect that some
>> functionality *will* break.  That's okay in my application.
> 
> But you are wrong.  There are non-terminating situations in unveil
> and pledge, where a program which doesn't test for unexpected error
> returns or specific errno's, as this is NOT A CORRECT POSIX ENVIRONEMT,
> will go down a wrong path and do the wrong thing.

In many cases, these are throwaway programs, often used to share
snippets.  In others, I would be fine with picking up the pieces
myself if things break.  What I am NOT fine with is having to run
a web application as root, or give it access to doas(1).

I am also not wedded to execpromises at all.  If there is a better
alternative, I would be more than happy to use it.  I am just not
aware of one.

Sincerely,

Demi

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Theo de Raadt]

>My primary use-case is that I would like to port a Linux web app
>(the Rust Playground) to OpenBSD.  The Rust Playground allows
>users to supply arbitrary source code, which is then compiled
>and executed.  I have no control over the contents of said code,
>so I have no way to ensure that these programs will call pledge(2)
>themselves.  Calling pledge(2) externally allows me to sandbox the
>untrusted binaries.

No it does not.  You keep using that vague word "sandbox", the word
has become pointless because it allows people to handwave away concerns
about "what happens when the software hits the boundaries".  In a real
backyard sandbox when the toy truck falls outside the box onto the grass
it's no big deal, but in the tech-space sandbox means bolting on "security"
without investing in actual "security".

I'll give it one more shot.

pledge is not a virtual machine.

It is a deliberately designed collection of POSIX subsets.  Every
subset you can generate is non-complaint with POSIX.  You have no idea
if the correctly-operating program won't hit one of those behavioral
changes, and then it is performing unintended behaviour.  The addition
of unveil and pledge enforcement has violated the assumptions of the
original program.  At a very fundamental level the program will
misbehave because you are putting it into an incorrect execution
environment.  The "containment method" WILL introduce changes in program
behaviour.

Let me be clear, the process you are engaging in is not ENGINEERING.
It is much closer to moving sand with plastic Tonka trucks.

>To be clear, I am only using execpromises because it is the only way
>I know of to solve my problem under OpenBSD.

I thought there were good usage cases for execpromises when I designed
it, but I've been unable to find them.

I was hoping people would not abuse it, but here we are.  You are
blindly accepting downsides which you cannot see.

That is why I intend to delete execpromises.

Re: Bluetooth adapter that works with OpenBSD

[Zé Loff]

On Tue, Sep 22, 2020 at 07:07:42AM -, Stuart Henderson wrote:
> On 2020-09-22, Tito Mari Francis Escaño  wrote:
> > Hi misc,
> > I'm building an OpenBSD desktop PC and would like to use my Royal Kludge
> > RK71 mechanical keyboard with it via USB Bluetooth dongle.
> > Can somebody please point me to USB Bluetooth dongles tested working with
> > OpenBSD?
> 
> The only way to do bluetooth on OpenBSD is with an adapter that runs
> the bluetooth stack internally and presents as a standard USB device.
> 
> There are several that do this for audio, Creative BT-W2 definitely
> works but there are others that may work too.
> 
> Some bluetooth devices can theoretically do this for human-interface devices 
> (mice/keyboards) too - it's how Apple has bluetooth working pre-boot -
> but I'm not aware of anyone having got them to work with OpenBSD.
> 
> https://www.businesswire.com/news/home/20030811005013/en/CSR-Saves-Stranded-Mice-HID-Proxy-Firmware
> ttps://www.0xf8.org/2014/02/the-crux-of-finding-a-hid-proxy-capable-usb-bluetooth-adapter/
> 

I found a Belkin adapter (model F8T016) that presents itself as a uhid
device (among other things):

I've read about other adapters that can switch between "OS managed"
(i.e. that show up as ugen) and "HID proxy" modes, but never got one.

In theory, my Belkin should be able to be paired to a bluetooth keyboard
and stay that way even across reboots.  The problem is that that
requires a keyboard that pairs without using a PIN, and my Logitech K380
doesn't, so I've never been able to get it to work as I wanted, nor test
if that is entirely true.  Even if I booted linux and paired the
keyboard with it, it won't stick across reboots, not even warm ones.
The keyboard was never available before the linux kernel and BT daemons
were loaded.

Sep 22 16:14:30 prionace /bsd: uhub8 at uhub0 port 13 configuration 1 interface 
0 "Broadcom BCM2046B1" rev 2.00/1.00 addr 7
Sep 22 16:14:31 prionace /bsd: uhidev4 at uhub8 port 1 configuration 1 
interface 0 "Broadcom product 0x4502" rev 2.00/1.00 addr 8
Sep 22 16:14:31 prionace /bsd: uhidev4: iclass 3/1, 1 report id
Sep 22 16:14:31 prionace /bsd: ukbd1 at uhidev4 reportid 1: 8 variable keys, 6 
key codes
Sep 22 16:14:32 prionace /bsd: wskbd2 at ukbd1 mux 1
Sep 22 16:14:32 prionace /bsd: wskbd2: connecting to wsdisplay0
Sep 22 16:14:32 prionace /bsd: uhidev5 at uhub8 port 2 configuration 1 
interface 0 "Broadcom product 0x4503" rev 2.00/1.00 addr 9
Sep 22 16:14:32 prionace /bsd: uhidev5: iclass 3/1, 125 report ids
Sep 22 16:14:32 prionace /bsd: ums1 at uhidev5 reportid 2: 3 buttons
Sep 22 16:14:32 prionace /bsd: wsmouse1 at ums1 mux 0
Sep 22 16:14:32 prionace /bsd: uhid5 at uhidev5 reportid 125: input=2, 
output=0, feature=0
Sep 22 16:14:33 prionace /bsd: ugen0 at uhub8 port 3 "Broadcom Corp BLUETOOTH 
USB +EDR ADAPTER v2.1 UHE" rev 2.00/3.88 addr 10

In summary: not only it is hard to find a device that works, you'd also
have to find a keyboard that pairs without a PIN and keep your fingers
firmly crossed.

-- 
 

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Demi M. Obenour]

On 2020-09-22 09:58, Ingo Schwarze wrote:
> Hi Demi,
> 
> Demi M. Obenour wrote on Mon, Sep 21, 2020 at 12:51:34PM -0400:
> 
>> The tool makes essential use of the execpromises argument
>> to pledge(2), so that it can sandbox the program it executes.
> 
> This appears to conflict with the basic idea of pledge(2), which
> is for the *programmer* to first do simple preparatory work that
> requires full syscall access, then pledge(2) according to a precise
> understanding of what the program is supposed to do during normal
> operation.  Usually, it is not possible to properly pledge(2) a
> program without designing it for pledge(2), sometimes called
> "hoisting".  As a corollary, pledging a program from the outside,
> without changing the code that is compiled, usually does not
> provide significant benefit.

I generally agree with you.  I do believe that there are a few
exceptions, however, as I wrote in my reply to de Raadt.

>> While I understand that this argument is slated for removal,
>> pledge(1) would not be possible without it.
> 
> Exactly, so this is not likely to go anywhere.
> 
>> pledge(1) is mainly intended for when the program being sandboxed
>> is either potentially malicious,
> 
> Even in such cases, pledge(2) needs to be called from *within*
> the program.  And that is what porters actually do.  Two examples
> of programs that are very obviously malicious are firefox and
> chromium.  Still, both call pledge(2) from within.

My primary use-case is that I would like to port a Linux web app
(the Rust Playground) to OpenBSD.  The Rust Playground allows
users to supply arbitrary source code, which is then compiled
and executed.  I have no control over the contents of said code,
so I have no way to ensure that these programs will call pledge(2)
themselves.  Calling pledge(2) externally allows me to sandbox the
untrusted binaries.

>> If there is interest, I would
>> also like to turn pledge(1) into a proper OpenBSD package at some
>> point, so that it can be installed using pkg_add(1).
> 
> That might (potentially) meet resistance from porters because
> it might stand in the way of deleting the execpromises feature
> when the time comes.

To be clear, I am only using execpromises because it is the only way
I know of to solve my problem under OpenBSD.  If there is a better
replacement for execpromises, I will happily migrate to using it,
but right now, I am not aware of any.  Running each untrusted
process under a separate user account requires at least part of
the web application to run as root, which isn’t desirable.
Using execpromises allows the web application to run as an
unprivileged user.

> Yours,
>   Ingo

Sincerely,

Demi

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Theo de Raadt]

>I actually agree with this.  Designing a program with pledge in
>mind is always better.  However, that requires that the program be
>trusted, and there still may be some corner cases in which I can
>tighten down the pledge more than the program itself can.

I disagree. I don't believe you can correctly produce security, because
the pledge operation puts the program into an unexpected non-POSIX
operational environment, and will introduce new potential error conditions
the program does not expect.

>So I can sandbox ftp(1) more than ftp(1) can reasonably sandbox itself.

I very strongly disagree.  At best the pledge/unveil-wrapper will work in
a specific one-time configuration, and not be generalizable.

We do not want users to be experimenting with things they don't understand,
more precisely, things they cannot understand because this high-level pledge
command is changing big underlying conditions.

>To be fair, one could argue that ftp(1) should have a command-line
>option that enables these lockdown options and disables the features
>unsupported under this mode.

Disagree.  This is not supposed to be user visible.

>That isn’t actually not the main use case for pledge(1),
>at least for me.  The main use-case is to sandbox untrusted,
>potentially malicious executables.

That is propostrous.

You think it's a good idea to throw untrusted programs into an
environment they were not designed...

But I argue the behavioral changes (especially relating the unveil not
seeing files, or the subtle behaviour of pledge around "stat", or
lockeds objects being left lingering when the program terminates
unexpected, are *USER HOSTILE*, and we don't want to help people using
this excessively sharp tool cutting their hands off and coming to misc@
to tell us long stories which summarize to "I am using pledge wrong
and I don't understand the failure modes"

>I do not know any way to
>implement something like the Rust Playground securely on OpenBSD
>without using execpromises, at least without requiring at least part
>of the application to run as root.  With execpromises, sandboxing
>untrusted executables is trivial.  That’s what pledge(1) is for.

No it is not trivial!  You are running code in *NON-POSIX MODES*.

>In my main use-case, I know what pledges I am willing to allow
>untrusted code to have.  If it tries to do something that the
>sandbox doesn’t allow, it *should* fail.  I expect that some
>functionality *will* break.  That’s okay in my application.

But you are wrong.  There are non-terminating situations in unveil
and pledge, where a program which doesn't test for unexpected error
returns or specific errno's, as this is NOT A CORRECT POSIX ENVIRONEMT,
will go down a wrong path and do the wrong thing.

That is the opposite of sandboxing.

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Demi M. Obenour]

On 2020-09-22 10:10, Theo de Raadt wrote:
> I gotta comment..

Thank you for your feedback.

>>> The tool makes essential use of the execpromises argument
>>> to pledge(2), so that it can sandbox the program it executes.
>>
>> This appears to conflict with the basic idea of pledge(2), which
>> is for the *programmer* to first do simple preparatory work that
>> requires full syscall access, then pledge(2) according to a precise
>> understanding of what the program is supposed to do during normal
>> operation.  Usually, it is not possible to properly pledge(2) a
>> program without designing it for pledge(2), sometimes called
>> "hoisting".
> 
> In the simplest cases, pledge removes some support operations, in
> particular relating options hiding under ioctl.  More complicated
> pledge use cases follow a "successive drop" feature as program
> initialization starts.
> 
> With this kind of pledge-from-parent, the sophisticated cases are
> impossible.

I actually agree with this.  Designing a program with pledge in
mind is always better.  However, that requires that the program be
trusted, and there still may be some corner cases in which I can
tighten down the pledge more than the program itself can.

For example, ftp(1) must consider all possible places the sysadmin
might put their CA certificates.  It also might need to execute
commands as part of interactive mode.  However, when using ftp(1)
as part of my modified sysupgrade(8), I know that the CA certificates
will be in the standard location, and that ftp(1) will never need to
exec(2) another program.  So I can sandbox ftp(1) more than ftp(1)
can reasonably sandbox itself.

To be fair, one could argue that ftp(1) should have a command-line
option that enables these lockdown options and disables the features
unsupported under this mode.  However, that would require that
every single program grow additional options, whereas pledge(1)
is very simple.

> Sadly, almost all programs bigger than "cat" or "more" require a
> huge pledge for initalization, especially if they do accept environment
> variables (themselves or in libc), or use the network.  So the pledge
> will always be huge.
> 
>> As a corollary, pledging a program from the outside,
>> without changing the code that is compiled, usually does not
>> provide significant benefit.
> 
> I agree.  I wrote a command like this myself, when I developed the
> execpromises featureset.  I am ready to delete exec promises because
> I consider it a failed experiment.
> 
> I found that useful application was extremely rare.  I could not even
> use execpromises properly in programs like "disklabel -E" to control
> the behaviour of the $EDITOR.

That isn’t actually not the main use case for pledge(1),
at least for me.  The main use-case is to sandbox untrusted,
potentially malicious executables.  I do not know any way to
implement something like the Rust Playground securely on OpenBSD
without using execpromises, at least without requiring at least part
of the application to run as root.  With execpromises, sandboxing
untrusted executables is trivial.  That’s what pledge(1) is for.

Much of the benefit of execpromises actually comes from being
able to preserve unveil(2) across execve(2).  I am perfectly okay
giving untrusted code "stdio rpath wpath cpath unix proc_exec",
for example, if unveil(2) has prevented it from accessing anything
important on the filesystem.  The other benefit of execpromises is
that it reduces the attack surface against the kernel, which makes
sandbox escapes significantly less likely.
 
> I've been down this road before, and it doesn't work.  You can come
> to this conclusion by finding a program, and trying *absolutely everything*
> it does, including environment variables and file openings and such that
> the libraries do.  You'll begin with optimism, but eventually add more and
> more pledges.

In my main use-case, I know what pledges I am willing to allow
untrusted code to have.  If it tries to do something that the
sandbox doesn’t allow, it *should* fail.  I expect that some
functionality *will* break.  That’s okay in my application.

> There's one more thing I want to mention:  pledge("shitload of options")
> intentionally is a non-POSIX compliant environment.  Command line users
> won't understand the edge conditions.

I agree.  pledge(1) is meant for advanced users and for those
implementing sandboxes.

Sincerely,

Demi M. Obenour

Re: OpenDNSSEC signer engine: Bus error: How to get debug information?

[Theo de Raadt]

> > #1  0x084fca6e4e55 in ixfr_del_rr (ixfr=0x852782d0d80, 
> > rr=0xdfdfdfdfdfdfdfdf) at signer/ixfr.c:134
> this is a use after free 
> 

damn right

Re: OpenDNSSEC signer engine: Bus error: How to get debug information?

[Florian Obser]

On Tue, Sep 22, 2020 at 04:08:16PM +0200, Why 42? The lists account. wrote:
> 
> On Tue, Sep 22, 2020 at 07:12:47AM -, Stuart Henderson wrote:
> > Sounds like they are trapping sigbus themselves but the handler isn't
> > giving useful information.
> > 
> > Try just running it under gdb:
> > pkg_add gdb
> > egdb ods-signerd
> > set args -dv
> > run
> > 
> > and see if you can get a backtrace. You may need to build opendnssec
> > with debug symbols to get a usable trace though (checkout the ports
> > tree and build it with "make DEBUG=-g repackage reinstall").
> 
> Hi Stuart,
> 
> Thanks for that, concise and really helpful. The debug build process was
> easier than I expected :).
> 
> For what is worth the results in egdb are:
> Thread 2 received signal SIGBUS, Bus error.
> [Switching to thread 478985]
> 0x0851fb90f5f5 in ldns_rr_clone () from /usr/local/lib/libldns.so.7.1
> (gdb) bt
> #0  0x0851fb90f5f5 in ldns_rr_clone () from /usr/local/lib/libldns.so.7.1
> #1  0x084fca6e4e55 in ixfr_del_rr (ixfr=0x852782d0d80, 
> rr=0xdfdfdfdfdfdfdfdf) at signer/ixfr.c:134
 this is a use after free 


> #2  0x084fca6ea0da in rrset_sign (ctx=0x8522842d800, rrset= out>, signtime=1600781131) at signer/rrset.c:758
> #3  0x084fca6ddd6c in drudge (worker=0x8521a9e4000) at 
> daemon/signertasks.c:196
> #4  0x084fca714e0b in runthread (data=0x851d1fc6300) at janitor.c:318
> #5  0x0852553ad0d1 in _rthread_start (v=) at 
> /usr/src/lib/librthread/rthread.c:96
> #6  0x0851f742dc38 in __tfork_thread () at 
> /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
> #7  0x in ?? ()
> (gdb) info args
> No symbol table info available.
> (gdb) info local
> No symbol table info available.
> (gdb) up
> #1  0x084fca6e4e55 in ixfr_del_rr (ixfr=0x852782d0d80, 
> rr=0xdfdfdfdfdfdfdfdf) at signer/ixfr.c:134
> 134   ldns_rr* rr_copy = ldns_rr_clone(rr);
> (gdb) info args
> ixfr = 0x852782d0d80
> rr = 0xdfdfdfdfdfdfdfdf
> (gdb) info local
> rr_copy = 
> 
> I'm not a gdb expert, but I wonder why it says "No symbol table info
> available" ...
> 
> In any case, I've forwarded the info. on to the opendnssec developer
> list.
> 
> Thanks again.
> 
> Cheers,
> Robb.
> 

-- 
I'm not entirely sure you are real.

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Theo de Raadt]

I gotta comment..

>> The tool makes essential use of the execpromises argument
>> to pledge(2), so that it can sandbox the program it executes.
>
>This appears to conflict with the basic idea of pledge(2), which
>is for the *programmer* to first do simple preparatory work that
>requires full syscall access, then pledge(2) according to a precise
>understanding of what the program is supposed to do during normal
>operation.  Usually, it is not possible to properly pledge(2) a
>program without designing it for pledge(2), sometimes called
>"hoisting".

In the simplest cases, pledge removes some support operations, in
particular relating options hiding under ioctl.  More complicated
pledge use cases follow a "successive drop" feature as program
initialization starts.

With this kind of pledge-from-parent, the sophisticated cases are
impossible.

Sadly, almost all programs bigger than "cat" or "more" require a
huge pledge for initalization, especially if they do accept environment
variables (themselves or in libc), or use the network.  So the pledge
will always be huge.

>As a corollary, pledging a program from the outside,
>without changing the code that is compiled, usually does not
>provide significant benefit.

I agree.  I wrote a command like this myself, when I developed the
execpromises featureset.  I am ready to delete exec promises because
I consider it a failed experiment.

I found that useful application was extremely rare.  I could not even
use execpromises properly in programs like "disklabel -E" to control
the behaviour of the $EDITOR.


I've been down this road before, and it doesn't work.  You can come
to this conclusion by finding a program, and trying *absolutely everything*
it does, including environment variables and file openings and such that
the libraries do.  You'll begin with optimism, but eventually add more and
more pledges.

There's one more thing I want to mention:  pledge("shitload of options")
intentionally is a non-POSIX compliant environment.  Command line users
won't understand the edge conditions.

Re: OpenDNSSEC signer engine: Bus error: How to get debug information?

[Why 42? The lists account.]

On Tue, Sep 22, 2020 at 07:12:47AM -, Stuart Henderson wrote:
> Sounds like they are trapping sigbus themselves but the handler isn't
> giving useful information.
> 
> Try just running it under gdb:
> pkg_add gdb
> egdb ods-signerd
> set args -dv
> run
> 
> and see if you can get a backtrace. You may need to build opendnssec
> with debug symbols to get a usable trace though (checkout the ports
> tree and build it with "make DEBUG=-g repackage reinstall").

Hi Stuart,

Thanks for that, concise and really helpful. The debug build process was
easier than I expected :).

For what is worth the results in egdb are:
Thread 2 received signal SIGBUS, Bus error.
[Switching to thread 478985]
0x0851fb90f5f5 in ldns_rr_clone () from /usr/local/lib/libldns.so.7.1
(gdb) bt
#0  0x0851fb90f5f5 in ldns_rr_clone () from /usr/local/lib/libldns.so.7.1
#1  0x084fca6e4e55 in ixfr_del_rr (ixfr=0x852782d0d80, 
rr=0xdfdfdfdfdfdfdfdf) at signer/ixfr.c:134
#2  0x084fca6ea0da in rrset_sign (ctx=0x8522842d800, rrset=, 
signtime=1600781131) at signer/rrset.c:758
#3  0x084fca6ddd6c in drudge (worker=0x8521a9e4000) at 
daemon/signertasks.c:196
#4  0x084fca714e0b in runthread (data=0x851d1fc6300) at janitor.c:318
#5  0x0852553ad0d1 in _rthread_start (v=) at 
/usr/src/lib/librthread/rthread.c:96
#6  0x0851f742dc38 in __tfork_thread () at 
/usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
#7  0x in ?? ()
(gdb) info args
No symbol table info available.
(gdb) info local
No symbol table info available.
(gdb) up
#1  0x084fca6e4e55 in ixfr_del_rr (ixfr=0x852782d0d80, 
rr=0xdfdfdfdfdfdfdfdf) at signer/ixfr.c:134
134 ldns_rr* rr_copy = ldns_rr_clone(rr);
(gdb) info args
ixfr = 0x852782d0d80
rr = 0xdfdfdfdfdfdfdfdf
(gdb) info local
rr_copy = 

I'm not a gdb expert, but I wonder why it says "No symbol table info
available" ...

In any case, I've forwarded the info. on to the opendnssec developer
list.

Thanks again.

Cheers,
Robb.

Re: [ANNOUNCE] pledge(1): an unprivileged sandboxing tool for OpenBSD

[Ingo Schwarze]

Hi Demi,

Demi M. Obenour wrote on Mon, Sep 21, 2020 at 12:51:34PM -0400:

> The tool makes essential use of the execpromises argument
> to pledge(2), so that it can sandbox the program it executes.

This appears to conflict with the basic idea of pledge(2), which
is for the *programmer* to first do simple preparatory work that
requires full syscall access, then pledge(2) according to a precise
understanding of what the program is supposed to do during normal
operation.  Usually, it is not possible to properly pledge(2) a
program without designing it for pledge(2), sometimes called
"hoisting".  As a corollary, pledging a program from the outside,
without changing the code that is compiled, usually does not
provide significant benefit.

> While I understand that this argument is slated for removal,
> pledge(1) would not be possible without it.

Exactly, so this is not likely to go anywhere.

> pledge(1) is mainly intended for when the program being sandboxed
> is either potentially malicious,

Even in such cases, pledge(2) needs to be called from *within*
the program.  And that is what porters actually do.  Two examples
of programs that are very obviously malicious are firefox and
chromium.  Still, both call pledge(2) from within.

> If there is interest, I would
> also like to turn pledge(1) into a proper OpenBSD package at some
> point, so that it can be installed using pkg_add(1).

That might (potentially) meet resistance from porters because
it might stand in the way of deleting the execpromises feature
when the time comes.

Yours,
  Ingo

pmap_unwire: wiring for pmap error

[Valdrin Muja]

Hi Misc,
I'm getting some error messages on dmesg but couldn't understand what's really 
going on.
I have one binary running under OpenBSD 6.7 and it crashes few times in a day.
Also, system is working slowly.For example, when I run "ifconfig" command it 
runs for a few seconds..

I see these error messages at dmesg:
pmap_unwire: wiring for pmap 0xfd8782e1b710 va 0xc00032c000 didn't change!
pmap_unwire: wiring for pmap 0xfd8782e1b710 va 0xc000b39000 didn't change!
pmap_unwire: wiring for pmap 0xfd8782e1b710 va 0xc000a3a000 didn't change!
pmap_unwire: wiring for pmap 0xfd8782e1b710 va 0xc000b2b000 didn't change!
pmap_unwire: wiring for pmap 0xfd8782e1b710 va 0xc000857000 didn't change!
Here full dmesg
OpenBSD 6.7 ([GENERIC.MP](http://generic.mp/)) #182: Thu May 7 11:11:58 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/[GENERIC.MP](http://generic.mp/)
real mem = 34302062592 (32712MB)
avail mem = 33249861632 (31709MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f31b000 (54 entries)
bios0: vendor American Megatrends Inc. version "5.13" date 04/10/2019
bios0: Default string Default string
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT FIDT MCFG WDAT APIC BDAT HPET UEFI SSDT DMAR SPCR 
HEST BERT ERST EINJ WSMT
acpi0: wakeup devices PEX0(S0) PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) PEX5(S0) 
PEX6(S0) PEX7(S0) XHC1(S4) LAN1(S0) LAN0(S0) LAN2(S0) LAN3(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.41 MHz, 06-5f-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 2MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 25MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.03 MHz, 06-5f-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 2MB 64b/line 16-way L2 cache
cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 8 (application processor)
cpu2: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.03 MHz, 06-5f-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 2MB 64b/line 16-way L2 cache
cpu2: smt 0, core 4, package 0
cpu3 at mainbus0: apid 12 (application processor)
cpu3: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.03 MHz, 06-5f-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 2MB 64b/line 16-way L2 cache
cpu3: smt 0, core 6, package 0
cpu4 at mainbus0: apid 16 (application processor)
cpu4: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.03 MHz, 06-5f-01
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu4: 2MB 64b/line 16-way L2 cache
cpu4: smt 0, core 8, package 0
cpu5 at mainbus0: apid 20 (application processor)
cpu5: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.03 

Nextcloud large file downloads fail (httpd, postgresql, php7.3)

[Unicorn]

Hello,

I have been encoutering this issue on several machines and have not
been able to locate the cause even after days worth of searching, let
alone find a solution (although I tried many things).

Basically, downloading a large file (1.2GB Video in this case) through
my web browser simply fails once a certain amount as been downloaded.
On one of my machines (4GB RAM) this happens around the 800MB-1GB
mark, on another (2GB RAM) this happens around the 400-500MB mark.

I have tried increasing PHP's memory_limit, max_input_time,
max_execution_time, post_max_size, upload_max_filesize and
opcache.memory_consumption, to no avail.

I have set the following values similar to the example httpd.conf in
the pkg-readme for nextcloud, additionally increasing the max request
body from 513M to 4GB (although it fails similarly with both):

# Set max upload size to 4GB (in bytes)
connection max request body 4294967296
connection max requests 1000
connection request timeout 3600
connection timeout 3600

My only clue was the difference between the two machines being roughly
proportional to their RAM size, but I do not understand this since I
only observed RAM usage of around 50% by httpd (observed with ps aux).

I am simply running out of ideas and struggling to find the cause of
the issue, so I would appreciate any advice or places/settings/logs to
look for an answer.

Please let me know if you need additional information to help me, I am
happy to provide it!

Best,
Unicorn

Re: OpenDNSSEC signer engine: Bus error: How to get debug information?

[Stuart Henderson]

On 2020-09-21, Why 42? The lists account.  wrote:
>
> Hi All,
>
> I am attempting to setup secure DNS on an OpenBSD 6.7 system using NSD,
> Unbound and a package called Opendnssec.
>
> I seem to have arrived at a point where one of the Opendnssec daemons,
> "ods-signerd", crashes on startup i.e.
>> # ods-signerd -dv
>> OpenDNSSEC signer engine version 2.1.6
>> Bus error in ldns_rr_clone
>> Threaddump
>> Threaddump
>> Threaddump
>> Threaddump
>> Threaddump
>> Threaddump
>> Threaddump
>> Threaddump
>> Threaddump
>> Threaddump
>> Bus error
>
> I'm not sure exactly what Threaddump means but, as far as I can tell, no
> core file is dumped/written.

Sounds like they are trapping sigbus themselves but the handler isn't
giving useful information.

Try just running it under gdb:

pkg_add gdb
egdb ods-signerd
set args -dv
run

and see if you can get a backtrace. You may need to build opendnssec
with debug symbols to get a usable trace though (checkout the ports
tree and build it with "make DEBUG=-g repackage reinstall").

Re: Bluetooth adapter that works with OpenBSD

[Stuart Henderson]

On 2020-09-22, Tito Mari Francis Escaño  wrote:
> Hi misc,
> I'm building an OpenBSD desktop PC and would like to use my Royal Kludge
> RK71 mechanical keyboard with it via USB Bluetooth dongle.
> Can somebody please point me to USB Bluetooth dongles tested working with
> OpenBSD?

The only way to do bluetooth on OpenBSD is with an adapter that runs
the bluetooth stack internally and presents as a standard USB device.

There are several that do this for audio, Creative BT-W2 definitely
works but there are others that may work too.

Some bluetooth devices can theoretically do this for human-interface devices 
(mice/keyboards) too - it's how Apple has bluetooth working pre-boot -
but I'm not aware of anyone having got them to work with OpenBSD.

https://www.businesswire.com/news/home/20030811005013/en/CSR-Saves-Stranded-Mice-HID-Proxy-Firmware
ttps://www.0xf8.org/2014/02/the-crux-of-finding-a-hid-proxy-capable-usb-bluetooth-adapter/

Re: dump LOB status

[Otto Moerbeek]

On Mon, Sep 21, 2020 at 10:23:55PM +0300, Juha Erkkilä wrote:

> 
> 
> > On 16. Sep 2020, at 20.27, Juha Erkkilä  wrote:
> > 
> > 
> >> On 16. Sep 2020, at 0.18, Kenneth Gober  wrote:
> >> I took a very quick look at the source and it appears that 213 is shown in
> >> octal.  I believe that the 200 bit indicates that a core file was produced,
> >> and 13 is probably a signal number (13 octal equals 11 decimal which would
> >> be SIGSEGV).  I am not sure whether the size of the file system is itself
> >> the cause, I have been using dump(8) to back up a large (currently 6.7TB)
> >> volume to tape for years (several tapes, actually) and it works fine,
> >> although that system is still on 6.1/amd64.  I looked in CVS and didn't see
> >> any obvious diffs between 6.1 and 6.6 that jumped out at me as potential
> >> causes, so perhaps the issue has been latent for a long time and I haven't
> >> seen it because it's triggered by the particulars of one or more files
> >> rather than the overall file system size.  Maybe if an individual file gets
> >> too big, or is too 'sparse' or something?
> > 
> > I can reproduce this on -current from Fri Sep 11 11:30:09
> > with a freshly created and an empty filesystem of 2 terabytes.
> 
> It looks like the same issue has been fixed in
> FreeBSD: https://svnweb.freebsd.org/base?view=revision=334979 
> 
> 
> The diff applies cleanly to the current OpenBSD source tree.

Maybe by hand, but not by using patch(1), the context differs a bit.

Next obvious question: did you test if it fixes your problem? That
means, do you get a dump that can be restored again?

-Otto