Re: mounting an existing softraid/crypto partition for install/update
YESS!! Thank you qwerjkl...
I can confirm, "bioctl -c C -l ... softraid0" seems to have picked up the
existing partition...and after a "cd /dev && sh MAKEDEV sd2", the installer
was picked up the device (sd2), and I was able to get back to a working
system.
Thanks again!
On Mon, Jun 3, 2019 at 7:30 PM Benny wrote:
> I have done that two days ago. When you use bioctl -c ... -l ... softraid0
> on an existing raid configuration, it will map the raid volume to another
> sd device. You will be prompted for a password if your raid level is
> crypto. This will _not_ create another raid or overwrite your data, unless
> you typed something wrong. Don't forget to MAKEDEV sd1 for the new sd.
>
> qwerjkl
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, June 3, 2019 7:17 PM, Bryan Stenson
> wrote:
>
> > Hi all -
> >
> > I'm running -CURRENT on a SSD with FDE encryption using softraid/crypto
> > with a passphrase entered via the keyboard at boot. It worked great.
> > Then, I upgraded to a build that had a broken bootloader (reported to be
> > fixed now: "Re: amd64 snapshot very broken (Jun 1 02:24:13)"). Per that
> > thread, I'm trying to boot from temp boot media to update to the fixed
> > image.
> >
> > I've tried booting both snapshots/amd64/install65.fs and
> > snapshots/amd64/miniroot65.fs, and while it appears the bootloader
> > recognizes my softraid crypto device, it's clearly not mounting the
> crypto
> > device (I'm not prompted for a passphrase), and by the time I get to the
> > install script, it shows:
> >
> > Available disks are: .
> > Which disk is the root disk? ('?' for details)
> >
> > Asking for details, both my SSD (sd0) and temp boot media (sd1) are
> shown,
> > but I'm not able to see the encrypted device.
> >
> > I've dropped to a shell, and created the device (it wasn't there) via "cd
> > /dev && sh MAKEDEV sd0", and can see my RAID partition via "disklabel
> sd0".
> >
> > But, now I'm stuck/confused...I'm trying to figure it out by following:
> > https://www.openbsd.org/faq/faq14.html#softraidFDE
> >
> > Do I re-create the softraid/crypto with something like "bioctl -c C sd0a
> > softraid0"? Or, will this will wipe out the existing data and give me a
> > fresh new partition to install to?
> >
> > How can I mount the existing crypto volume for use by the installer?
> > (Also, am I asking the right questions here?)
> >
> > Any suggestions/clarifications would be greatly appreciated. Thank you
> for
> > your time.
> >
> > Bryan
>
>
>
Re: mounting an existing softraid/crypto partition for install/update
On 6/3/19 8:17 PM, Bryan Stenson wrote:
> Hi all -
>
> I'm running -CURRENT on a SSD with FDE encryption using softraid/crypto
> with a passphrase entered via the keyboard at boot. It worked great.
> Then, I upgraded to a build that had a broken bootloader (reported to be
> fixed now: "Re: amd64 snapshot very broken (Jun 1 02:24:13)"). Per that
> thread, I'm trying to boot from temp boot media to update to the fixed
> image.
ouch. :(
> I've tried booting both snapshots/amd64/install65.fs and
> snapshots/amd64/miniroot65.fs, and while it appears the bootloader
> recognizes my softraid crypto device, it's clearly not mounting the crypto
> device (I'm not prompted for a passphrase), and by the time I get to the
> install script, it shows:
>
> Available disks are: .
> Which disk is the root disk? ('?' for details)
>
> Asking for details, both my SSD (sd0) and temp boot media (sd1) are shown,
> but I'm not able to see the encrypted device.
>
> I've dropped to a shell, and created the device (it wasn't there) via "cd
> /dev && sh MAKEDEV sd0", and can see my RAID partition via "disklabel sd0".
You probably need to make sd1 and sd2, as well (sd1 your install media,
will probably be made for you, but as long as you are in the
neighborhood... sd2 will hold the actual file systems on the encrypted
"disk" that you will be installing to.
> But, now I'm stuck/confused...I'm trying to figure it out by following:
> https://www.openbsd.org/faq/faq14.html#softraidFDE
>
> Do I re-create the softraid/crypto with something like "bioctl -c C sd0a
> softraid0"? Or, will this will wipe out the existing data and give me a
> fresh new partition to install to?
yep.
bioctl -c C -l /dev/sd0a softraid0
should do it. I'm just peeking at a script I use to manually mount an
encrypted file system post-boot.
> How can I mount the existing crypto volume for use by the installer?
> (Also, am I asking the right questions here?)
Once you have "unlocked" the encryped partition and it becomes a new
logical drive, make note of that, and answer that drive to the installer
if it doesn't figure it out on its own.
Nick.
Re: mounting an existing softraid/crypto partition for install/update
I have done that two days ago. When you use bioctl -c ... -l ... softraid0 on
an existing raid configuration, it will map the raid volume to another sd
device. You will be prompted for a password if your raid level is crypto. This
will _not_ create another raid or overwrite your data, unless you typed
something wrong. Don't forget to MAKEDEV sd1 for the new sd.
qwerjkl
‐‐‐ Original Message ‐‐‐
On Monday, June 3, 2019 7:17 PM, Bryan Stenson wrote:
> Hi all -
>
> I'm running -CURRENT on a SSD with FDE encryption using softraid/crypto
> with a passphrase entered via the keyboard at boot. It worked great.
> Then, I upgraded to a build that had a broken bootloader (reported to be
> fixed now: "Re: amd64 snapshot very broken (Jun 1 02:24:13)"). Per that
> thread, I'm trying to boot from temp boot media to update to the fixed
> image.
>
> I've tried booting both snapshots/amd64/install65.fs and
> snapshots/amd64/miniroot65.fs, and while it appears the bootloader
> recognizes my softraid crypto device, it's clearly not mounting the crypto
> device (I'm not prompted for a passphrase), and by the time I get to the
> install script, it shows:
>
> Available disks are: .
> Which disk is the root disk? ('?' for details)
>
> Asking for details, both my SSD (sd0) and temp boot media (sd1) are shown,
> but I'm not able to see the encrypted device.
>
> I've dropped to a shell, and created the device (it wasn't there) via "cd
> /dev && sh MAKEDEV sd0", and can see my RAID partition via "disklabel sd0".
>
> But, now I'm stuck/confused...I'm trying to figure it out by following:
> https://www.openbsd.org/faq/faq14.html#softraidFDE
>
> Do I re-create the softraid/crypto with something like "bioctl -c C sd0a
> softraid0"? Or, will this will wipe out the existing data and give me a
> fresh new partition to install to?
>
> How can I mount the existing crypto volume for use by the installer?
> (Also, am I asking the right questions here?)
>
> Any suggestions/clarifications would be greatly appreciated. Thank you for
> your time.
>
> Bryan
mounting an existing softraid/crypto partition for install/update
Hi all -
I'm running -CURRENT on a SSD with FDE encryption using softraid/crypto
with a passphrase entered via the keyboard at boot. It worked great.
Then, I upgraded to a build that had a broken bootloader (reported to be
fixed now: "Re: amd64 snapshot very broken (Jun 1 02:24:13)"). Per that
thread, I'm trying to boot from temp boot media to update to the fixed
image.
I've tried booting both snapshots/amd64/install65.fs and
snapshots/amd64/miniroot65.fs, and while it appears the bootloader
recognizes my softraid crypto device, it's clearly not mounting the crypto
device (I'm not prompted for a passphrase), and by the time I get to the
install script, it shows:
Available disks are: .
Which disk is the root disk? ('?' for details)
Asking for details, both my SSD (sd0) and temp boot media (sd1) are shown,
but I'm not able to see the encrypted device.
I've dropped to a shell, and created the device (it wasn't there) via "cd
/dev && sh MAKEDEV sd0", and can see my RAID partition via "disklabel sd0".
But, now I'm stuck/confused...I'm trying to figure it out by following:
https://www.openbsd.org/faq/faq14.html#softraidFDE
Do I re-create the softraid/crypto with something like "bioctl -c C sd0a
softraid0"? Or, will this will wipe out the existing data and give me a
fresh new partition to install to?
How can I mount the existing crypto volume for use by the installer?
(Also, am I asking the right questions here?)
Any suggestions/clarifications would be greatly appreciated. Thank you for
your time.
Bryan
chrome pledge "", syscall 289
Hi, I have found the following errors on the log: /bsd: chrome[18585]: pledge "", syscall 289 they appear everytime I start chrome.. they are about 4 or 5, what means? It's the first time, yesterday and in the past there aren't any. thx cord
Re: Let's Encrypt ACMEv1 end-of-life
Diogo Pinela [dpin...@ipatimup.pt] wrote: > > That's interesting, but it doesn't answer my question at all. I don't know if Kristaps is planning on updating it. Nobody else has mentioned it. Maybe it's a prime job for you to investigate? The final RFC version, ACMEv2, is documented in RFC 8555: https://www.rfc-editor.org/rfc/rfc8555.txt Chris
Re: Security of OpenBSD
> 4. jun. 2019 kl. 00:32 skrev Josef Pospisil : > > Can someone be that kind and explain to me if the whole code of OpenBSD > was checked at least once since the openBSD was founded? That there are > no backholes like i was describing? Code auditing (aka ‘reading the code like the devil reads the Bible’) is very much part of the project lifestyle. A good place to start for taking in how the project works is the project website itself, start at the top with the project goals page http://www.openbsd.org/goals.html and work your way through at your own pace. There are of course other, less official propaganda presentations like my own «OpenBSD and you» (https://home.nuug.no/~peter/openbsd_and_you/) that will if nothing else show you highlights I thought important while composing a user group presentation (and some minor brushups since then), with links to further info. - Peter — Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. signature.asc Description: Message signed with OpenPGP
Re: Security of OpenBSD
I think the OpenBSD code review is taken so seriously thank is more than a good practice matter. https://www.openbsd.org/security.html Em seg, 3 de jun de 2019 às 22:33, Josef Pospisil escreveu: > Hey, thank you all for this mailing list. > > I have a question regarding the security of OpebBSD. > > I am asuming that linux has some mathematics and logic that lets you > get into every system just for e.g. because of portknocking! > That opens an Interface for people that know the system to do > everything! I also think that linux is not beeing verified ragarding > these paid programer backholes. > > Can someone be that kind and explain to me if the whole code of OpenBSD > was checked at least once since the openBSD was founded? That there are > no backholes like i was describing? > > It would be beautifull if someone could answer me! > > Greetings > > Josef Pospisil > > >
syspatch(8) and patches requiring fw_update
In the latest mds errata patch, I noticed that one of the steps is to run fw_update. From briefly looking over the syspatch script, I don't see it calling fw_update once a patch is applied. Would you welcome a diff to add support for this? If so I can look at writing one. It would check against the .sig patch file itself, since the .tgz syspatch binary patch doesn't contain any details about needing to run fw_update. A rough set of steps would be: - Pull .sig patch from mirror and verify signature - Parse for fw_update - Once the patch has been applied, run fw_update Please let me know of any feedback to this approach. Andrew
opensmtpd forwarding sent mail and extras-pgsql
Hi, I am planning a mail server of opensmtpd and dovecot. I'd be glad to know if there is any way to save a copy of mail to dovecot's "Sent" mail box before relaying them out. I am also not about find any docs on opensmtpd-extra-pgsql. Is there any guide to link postgresql up with smtpd for virtual users? Thanks qwerjkl
Re: Can't update BIOS on alix2d13 with flashrom
On 2019-06-02, Артур Истомин wrote:
> I'm trying update BIOS on alix2d13 board with flashrom ver 1.0 on OpenBSD 6.5
>
> # flashrom -w alix1.bin -p internal
> flashrom v1.0 on OpenBSD 6.5 (i386)
> flashrom is free software, get the source code at https://flashrom.org
>
> Calibrating delay loop... delay loop is unreliable, trying to continue OK.
> No DMI table found.
> Found chipset "AMD CS5536".
> Enabling flash write... Error while opening /dev/amdmsr: Device not configured
> FAILED!
> Warning: unexpected second chipset match: "AMD CS5536"
> ignoring, please report lspci and board URL to flash...@flashrom.org
> with 'CHIPSET: your board name' in the subject line.
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.
>
> What's wrong?
Looks like this flash device can only be programmed with model-specific
registers (MSRs). On OpenBSD this is done via amdmsr(4) which requires
2 things: 1: it must be detected and attached in the kernel, and 2:
machdep.allowaperture must be set (normally on OpenBSD this device
is used for access to graphics with X).
If 1 fails you get ENXIO "Device not configured", if 2 fails you get
EPERM "Operation not permitted".
On your system the device does not attach (no amdmsr attach line in dmesg).
Looking at amdmsr_probe() in /sys/arch/i386/i386/amdmsr.c I see this
74 /* Check for AMD Geode LX CPU */
75 if (strcmp(cpu_vendor, "AuthenticAMD") == 0 && family == 0x5 &&
76 model == 0x0a) {
77 /* Check for graphics processor presence */
78 gld_msr_cap = rdmsr(GLX_CPU_GLD_MSR_CAP);
79 if (((gld_msr_cap >> 8) & 0x0fff) == GLX_CPU_DID) {
80 gld_msr_cap = rdmsr(GLX_GP_GLD_MSR_CAP);
81 if (((gld_msr_cap >> 8) & 0x0fff) == GLX_GP_DID)
82 return 1;
83 }
84 }
>
> dmesg:
>
> OpenBSD 6.5 (GENERIC) #1: Wed Apr 24 22:04:27 CEST 2019
> r...@syspatch-65-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 267931648 (255MB)
> avail mem = 247779328 (236MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 11/05/08, BIOS32 rev. 0 @ 0xfd088
> pcibios0 at bios0: rev 2.1 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xe/0xa800
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class)
> 499 MHz, 05-0a-02
The family/model (05/0a) match but the driver is not attaching so it must be
failing the "Check for graphics processor presence" check.
If you were to remove that check, maybe it will work, or maybe it will
fail horribly and you will brick your board.
Personally I would recommend following pcengines' suggested procedure
and use their freedos image for alix.
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> mtrr: K6-family MTRR support (2 registers)
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address
> 00:0d:b9:2b:d9:3c
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
> address 00:0d:b9:2b:d9:3d
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 15,
> address 00:0d:b9:2b:d9:3e
> ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> athn0 at pci0 dev 12 function 0 "Atheros AR9280" rev 0x01: irq 9
> athn0: AR9280 rev 2 (2T2R), ROM rev 21, address a8:54:b2:3e:02:e7
> glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit
> 3579545Hz timer, watchdog, gpio, i2c
> gpio0 at glxpcib0: 32 pins
> iic0 at glxpcib0
> maxtmp0 at iic0 addr 0x4c: lm86
> pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
> wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0:
> wd0: 1-sector PIO, LBA, 15279MB, 31293360 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 12, version
> 1.0, legacy support
> ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 12
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00
> addr 1
> isa0 at glxpcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at
Re: Let's Encrypt ACMEv1 end-of-life
On sáb, jun 1, 2019 at 3:42 PM, Patrick Dohman wrote: On May 31, 2019, at 10:42 AM, Diogo Pinela wrote: As I understand it, acme-client currently only supports ACMEv1. Let's Encrypt recently announced they're going to begin progressively deprecating that protocol starting this November: OCSP is an interesting subject. In my opinion there is still a need for a certificate infrastructure inside private LAN's. I’ve learned that in many situations a DNS authority can not be accommodated & certs are non-op. In addition I find the reliance on public API via browser a potential privacy concern. Regards Patrick That's interesting, but it doesn't answer my question at all.
Re: request for testing: bootstrapping time
On Mon, Jun 03, 2019 at 10:18:38AM -0400, sven falempin wrote:
> On Mon, Jun 3, 2019 at 1:44 AM Otto Moerbeek wrote:
> >
> > Hi,
> >
> > If you ever wanted to be more involved in OpenBSD here's a chanche:
> >
> > https://marc.info/?l=openbsd-tech&m=155950103825035&w=2
> >
> > It requires setting up a test machine running a recent snapshot, so
> > that's a nice first step. Then get the sources and apply the patch,
> > build and test
> >
> > You'll find help getting src and bulding the system in the FAQ.
> >
> > Much appreciated!
> >
> > -Otto
> >
>
> Dear readers,
>
> I'd like to share some result regarding ntpd , I did not yet configure
> DNSSEC and will try that later.
> I use a local unbound, and have some issue regarding time on some devices.
>
> on 6.0 I was unable to use constraint: it was not working.
> my current production version is 6.4, and I have 'problems' similar to
> the one nicely explain above,
> I still feel like a STDERR warning would be nice for -s flag failure,
> because reading log in rcctl like management script
> when time is not set is 'incomplete'.
>
> This is an important feature to TEST. ( thank you Otto for working on ntpd )
>
> I m running a slightly modified HEAD version in the test, see __why not__
> this is a * pre test *
>
> First I stopped ntpd and changed the date , then run with -ds
>
> badblock# rcctl stop ntpd && date 20180603.00 && ntpd -s
> ntpd(ok)
> Sun Jun 3 00:00:00 EDT 2018
> ntp engine ready
> trying to resolve www.google.com
> resolve www.google.com done: 2
> trying to resolve pool.ntp.org
> resolve pool.ntp.org done: 4
> constraint request to 2607:f8b0:4020:804::2004
> constraint request to 172.217.13.196
> tls connect failed: 2607:f8b0:4020:804::2004 (www.google.com):
> connect: No route to host
> no constraint reply from 2607:f8b0:4020:804::2004 received in time,
> next query 900s
> constraint reply from 172.217.13.196: offset 31567971.561072
> reply from 206.108.0.131: offset 31567971.791870 delay 0.016370, next query
> 8s
> set local clock to Mon Jun 3 08:53:04 EDT 2019 (offset 31567971.791870s)
> reply from 154.11.146.39: offset 15783985.894667 delay
> 31567971.873626, next query 5s
> reply from 209.115.181.107: offset 15783985.890166 delay
> 31567971.885181, next query 7s
> reply from 205.206.70.2: offset 15783985.888720 delay
> 31567971.886449, next query 6s
> reply from 154.11.146.39: offset -0.000489 delay 0.082025, next query 6s
> reply from 205.206.70.2: offset -0.011286 delay 0.087997, next query 6s
> reply from 206.108.0.131: offset 0.003587 delay 0.022641, next query 8s
> reply from 209.115.181.107: offset -0.006413 delay 0.091241, next query 9s
> reply from 154.11.146.39: offset 0.013697 delay 0.110286, next query 7s
> reply from 205.206.70.2: offset -0.010733 delay 0.091208, next query 9s
> reply from 206.108.0.131: offset 0.010468 delay 0.036784, next query 9s
> reply from 209.115.181.107: offset -0.01 delay 0.096816, next query 8s
> peer 154.11.146.39 now valid
>
> as we can read here in basic scenario the constraint will force the
> setup, when everything s fine, ….everything s fine !
> Assuming you have a nicely place anchor
> Let 's do : echo 'block on egress proto {tcp,udp} from any to any port
> ntp' | pfctl -f - -a 'top'
> or echo 'block on egress proto {tcp,udp} from any to any port ntp' >>
> /etc/pf.conf && pfctl -f /etc/pf.conf in a default setup.
> Things can get more interesting. I m not sure why but I had to modify
> my /etc/hosts to force ipv4 , no matter.
> Nevertheless:
>
> badblock# ntpd -sd
> ntp engine ready
> trying to resolve www.google.com
> resolve www.google.com done: 1
> trying to resolve pool.ntp.org
> resolve pool.ntp.org done: 4
> constraint request to 172.217.13.132
> constraint reply from 172.217.13.132: offset 31568246.201761
> set local clock to Sun Jun 3 00:42:25 EDT 2018 (offset 0.00s)
>
> ^Cntp engine exiting
> Terminating
> badblock# date
> Sun Jun 3 00:42:35 EDT 2018
> badblock# ntpd -sd
> ntp engine ready
> trying to resolve www.google.com
> resolve www.google.com done: 1
> trying to resolve pool.ntp.org
> resolve pool.ntp.org done: 4
> constraint request to 172.217.13.132
> constraint reply from 172.217.13.132: offset 31568246.593501
> set local clock to Sun Jun 3 00:42:39 EDT 2018 (offset 0.00s)
> ^Cntp engine exiting
> Terminating
>
> The clock suddenly refuse to be set up correctly with the HTTP header.
> And it is logged that clock is set : set local clock to Sun Jun 3
> 00:42:39 EDT 2018 (offset 0.00s)
> wrongly.
>
> Given the above proposition, the ULTRA_VIOLENCE mode may not be working
> as the clock wont be offset by the http header.
>
> I hope this *pretest* log may help other user to test this important
> bootstrapping.
> The above result is for me a problem, and I will have to thwart this
> first ( and find time for DNSSEC setup).
>
> NB: it is possible to have a network where HTTPS
Re: request for testing: bootstrapping time
On Mon, Jun 3, 2019 at 1:44 AM Otto Moerbeek wrote:
>
> Hi,
>
> If you ever wanted to be more involved in OpenBSD here's a chanche:
>
> https://marc.info/?l=openbsd-tech&m=155950103825035&w=2
>
> It requires setting up a test machine running a recent snapshot, so
> that's a nice first step. Then get the sources and apply the patch,
> build and test
>
> You'll find help getting src and bulding the system in the FAQ.
>
> Much appreciated!
>
> -Otto
>
Dear readers,
I'd like to share some result regarding ntpd , I did not yet configure
DNSSEC and will try that later.
I use a local unbound, and have some issue regarding time on some devices.
on 6.0 I was unable to use constraint: it was not working.
my current production version is 6.4, and I have 'problems' similar to
the one nicely explain above,
I still feel like a STDERR warning would be nice for -s flag failure,
because reading log in rcctl like management script
when time is not set is 'incomplete'.
This is an important feature to TEST. ( thank you Otto for working on ntpd )
I m running a slightly modified HEAD version in the test, see __why not__
this is a * pre test *
First I stopped ntpd and changed the date , then run with -ds
badblock# rcctl stop ntpd && date 20180603.00 && ntpd -s
ntpd(ok)
Sun Jun 3 00:00:00 EDT 2018
ntp engine ready
trying to resolve www.google.com
resolve www.google.com done: 2
trying to resolve pool.ntp.org
resolve pool.ntp.org done: 4
constraint request to 2607:f8b0:4020:804::2004
constraint request to 172.217.13.196
tls connect failed: 2607:f8b0:4020:804::2004 (www.google.com):
connect: No route to host
no constraint reply from 2607:f8b0:4020:804::2004 received in time,
next query 900s
constraint reply from 172.217.13.196: offset 31567971.561072
reply from 206.108.0.131: offset 31567971.791870 delay 0.016370, next query 8s
set local clock to Mon Jun 3 08:53:04 EDT 2019 (offset 31567971.791870s)
reply from 154.11.146.39: offset 15783985.894667 delay
31567971.873626, next query 5s
reply from 209.115.181.107: offset 15783985.890166 delay
31567971.885181, next query 7s
reply from 205.206.70.2: offset 15783985.888720 delay
31567971.886449, next query 6s
reply from 154.11.146.39: offset -0.000489 delay 0.082025, next query 6s
reply from 205.206.70.2: offset -0.011286 delay 0.087997, next query 6s
reply from 206.108.0.131: offset 0.003587 delay 0.022641, next query 8s
reply from 209.115.181.107: offset -0.006413 delay 0.091241, next query 9s
reply from 154.11.146.39: offset 0.013697 delay 0.110286, next query 7s
reply from 205.206.70.2: offset -0.010733 delay 0.091208, next query 9s
reply from 206.108.0.131: offset 0.010468 delay 0.036784, next query 9s
reply from 209.115.181.107: offset -0.01 delay 0.096816, next query 8s
peer 154.11.146.39 now valid
as we can read here in basic scenario the constraint will force the
setup, when everything s fine, ….everything s fine !
Assuming you have a nicely place anchor
Let 's do : echo 'block on egress proto {tcp,udp} from any to any port
ntp' | pfctl -f - -a 'top'
or echo 'block on egress proto {tcp,udp} from any to any port ntp' >>
/etc/pf.conf && pfctl -f /etc/pf.conf in a default setup.
Things can get more interesting. I m not sure why but I had to modify
my /etc/hosts to force ipv4 , no matter.
Nevertheless:
badblock# ntpd -sd
ntp engine ready
trying to resolve www.google.com
resolve www.google.com done: 1
trying to resolve pool.ntp.org
resolve pool.ntp.org done: 4
constraint request to 172.217.13.132
constraint reply from 172.217.13.132: offset 31568246.201761
set local clock to Sun Jun 3 00:42:25 EDT 2018 (offset 0.00s)
^Cntp engine exiting
Terminating
badblock# date
Sun Jun 3 00:42:35 EDT 2018
badblock# ntpd -sd
ntp engine ready
trying to resolve www.google.com
resolve www.google.com done: 1
trying to resolve pool.ntp.org
resolve pool.ntp.org done: 4
constraint request to 172.217.13.132
constraint reply from 172.217.13.132: offset 31568246.593501
set local clock to Sun Jun 3 00:42:39 EDT 2018 (offset 0.00s)
^Cntp engine exiting
Terminating
The clock suddenly refuse to be set up correctly with the HTTP header.
And it is logged that clock is set : set local clock to Sun Jun 3
00:42:39 EDT 2018 (offset 0.00s)
wrongly.
Given the above proposition, the ULTRA_VIOLENCE mode may not be working
as the clock wont be offset by the http header.
I hope this *pretest* log may help other user to test this important
bootstrapping.
The above result is for me a problem, and I will have to thwart this
first ( and find time for DNSSEC setup).
NB: it is possible to have a network where HTTPS is possible but NTP
blocked or invalid (or hacked), and
/etc/ssl/cert.pem + a valid ip/domain ( why not constraint https://a
valid ip/ ) trust level is above the BIOS for me.
Best.
tl;dr
And by the way, restricting or having custom certificate would be a
strong feature ntpd -c /etc/ssl/restricted.pem ,
also se
Re: amd64 snapshot very broken (Jun 1 02:24:13)
On 2019-06-01, Christian Weisgerber wrote: > The amd64 snapshot with BUILDINFO > Build date: 1559355853 - Sat Jun 1 02:24:13 UTC 2019 > is very broken. Specifically, the boot loader is broken. Sorry, I forgot to follow up: This has been fixed for more than a day now. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Can't update BIOS on alix2d13 with flashrom
On Mon, Jun 03, 2019 at 06:28:30AM +1000, Zach Nedwich wrote: > Did you try booting in single mode? "boot -s" at the boot prompt, then mount > -a to mount /usr/bin. No, I don't have serial port. For installing/upgrading OpenBSD, I'm using QEMU and CF-card/USB adapter. To run system with kern.securelevel=-1 I'm using /etc/rc.securelevel
Re: privilege escalation via vmmints?
On Mon, Jun 03, 2019 at 10:55:47AM +0200, Mara Toni wrote: > Hello, > > did anybody hear about the: > > https://vigilance.fr/vulnerability/OpenBSD-privilege-escalation-via-vmmints-28874 > > OpenBSD: privilege escalation via vmmints > Synthesis of the vulnerability > An attacker can bypass restrictions via vmmints of OpenBSD, in order to > escalate his privileges. > Vulnerable systems: OpenBSD. > Severity of this threat: 2/4. > Consequences of a hack: administrator access/rights, privileged access/rights. > Pirate's origin: user shell. > Creation date: 27/03/2019. > Références of this weakness: VIGILANCE-VUL-28874. > > any info on it? > > Thanks. > https://ftp.openbsd.org/pub/OpenBSD/patches/6.4/common/016_vmmints.patch.sig -ml
privilege escalation via vmmints?
Hello, did anybody hear about the: https://vigilance.fr/vulnerability/OpenBSD-privilege-escalation-via-vmmints-28874 OpenBSD: privilege escalation via vmmints Synthesis of the vulnerability An attacker can bypass restrictions via vmmints of OpenBSD, in order to escalate his privileges. Vulnerable systems: OpenBSD. Severity of this threat: 2/4. Consequences of a hack: administrator access/rights, privileged access/rights. Pirate's origin: user shell. Creation date: 27/03/2019. Références of this weakness: VIGILANCE-VUL-28874. any info on it? Thanks.
