Re: How boot HDD-side crypto softraid from (bootable) USB disk? (AMD64/ARM. Currently installboot fails with "cross-device install"!..)
On 2017-02-06, Tinker wrote: > How use a HDD as crypto softraid root filesystem media, but put boot > code and cryto softraid keydisk partition (and perhaps /boot file and/or > kernel) on an USB disk? Create a bootable OpenBSD area with two OpenBSD partitions on the USB stick: 'a' with type 4.2BSD and let's say 'd' with type RAID. They can be really small, 1MB each is fine: #size offset fstype [fsize bsize cpg] a: 2048 64 4.2BSD 2048 1638464 c: 79288320 unused d: 2048 2112RAID i: 7924672 4160 MSDOS Let's say the USB stick is sd1. Create a filesystem with newfs(8) on sd1a. Mount this partition, say on /mnt. Create a directory /mnt/etc/ and a file /mnt/etc/boot.conf with the line set device sr0a Install a bootstrap to the USB stick with # installboot -r /mnt sd1 /usr/mdec/biosboot /usr/mdec/boot Later, when you create the softraid crypto volume, use the USB stick's other OpenBSD partition as key disk. E.g.: # bioctl -c C -k sd1d -l sd0a softraid0 When you boot from the USB stick, the unencrypted boot loader on 'a' is executed. It assembles the softraid volume, automagically using 'd' as the key disk. It next reads /etc/boot.conf from the stick's 'a' file system, then switches the boot device to the softraid volume, and runs the kernel there. Presto! -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: pkg_add: ftp: connect: Invalid argument
On Mon, Feb 06, 2017 at 09:18:09AM -0800, jungle Boogie wrote: > On 6 February 2017 at 04:41, Marc Espie wrote: > > On Sat, Feb 04, 2017 at 08:31:45PM -0800, jungle boogie wrote: > >> On 02/04/2017 05:45 PM, Philip Guenther wrote: > >> >On Sat, 4 Feb 2017, jungle boogie wrote: > >> >>What's happening here? > >> >> > >> >>$ doas pkg_add -u > >> >>Error from http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ > >> >>ftp: connect: Invalid argument > >> > > >> >Running that under ktrace -i might help see the problem, ala > >> > doas ktrace -i pkg_add -u > >> > > >> >then kdump | less and look for a failed connect call. Should be able to > >> >search for "connect -1 errno" and then go backwards to see the connect() > >> >call and the sockaddr passed to it. > >> > > >> > > >> > >> Here's where it actually lits the URL: > > > > perl doesn't do network connects in that context. > > just run > > ftp -o - http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ > > it should dump the html list of packages. > > > > if it doesn't, your network is broken. > > Ah, that's a good trick! I'll keep that in mind if there's a next time. Another important point: it's run as the _pkgfetch user. So if you have any kind of local pf rules that varies depending on user, that might be an issue. You should properly do something like doas -u _pkgfetch env -i ftp -o - http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ (unless you have proxy settings, in which case you should pass the proxy env variables thru as well) drop_privileges_and_setup_env is the routine that does it in PackageRepository.pm, and you can see it's quite picky about the part of the environment it lets thru...
RAP - Reuse Attack Protector
Just read it today, hopefully it could be useful for the OpenBSD team too: http://www.prweb.com/releases/2017/02/prweb14044396.htm https://grsecurity.net/rap_announce_ret.php https://grsecurity.net/download.php#test
Re: pkg_add: ftp: connect: Invalid argument
On 6 February 2017 at 04:41, Marc Espie wrote: > On Sat, Feb 04, 2017 at 08:31:45PM -0800, jungle boogie wrote: >> On 02/04/2017 05:45 PM, Philip Guenther wrote: >> >On Sat, 4 Feb 2017, jungle boogie wrote: >> >>What's happening here? >> >> >> >>$ doas pkg_add -u >> >>Error from http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ >> >>ftp: connect: Invalid argument >> > >> >Running that under ktrace -i might help see the problem, ala >> > doas ktrace -i pkg_add -u >> > >> >then kdump | less and look for a failed connect call. Should be able to >> >search for "connect -1 errno" and then go backwards to see the connect() >> >call and the sockaddr passed to it. >> > >> > >> >> Here's where it actually lits the URL: > > perl doesn't do network connects in that context. > just run > ftp -o - http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ > it should dump the html list of packages. > > if it doesn't, your network is broken. Ah, that's a good trick! I'll keep that in mind if there's a next time. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info
Re: How boot HDD-side crypto softraid from (bootable) USB disk? (AMD64/ARM. Currently installboot fails with "cross-device install"!..)
On 2017-02-06, Tinker wrote: > The following is for AMD64 though I'd guess that a similar approach > would be possible on other platforms also. > > The boot sequence with MBR is: > > MBR: Load PBR (unencrypted) > > PBR: Load /boot (encrypted) /boot is not encrypted. In fact, with root on softraid, there is no such file /boot. Since it needs to fit into 512 bytes, the biosboot(8) code in the PBR is very simple. It contains a hardcoded pointer where to find boot(8). Without softraid, installboot(8) installs /usr/mdec/boot as /boot, and /usr/mdec/biosboot into the PBR and patches it with the necessary information where to find /boot. At the start of a softraid partition there is a metadata area that holds various information about the softraid volume. This area includes reserved space for boot strapping: 320*512 bytes for the boot loader (plus 128*512 bytes for a boot block, unused on x86). See /usr/include/dev/softraidvar.h. This is outside any file system. With softraid, installboot(8) installs /usr/mdec/boot into the boot loader space of the softraid partition, and /usr/mdec/biosboot into the PBR and patches it with the necessary information where to find the boot loader. The PBR loads boot(8), unencrypted. The boot loader then assembles the softraid volume, which for a crypto volume includes asking the passphrase or locating the key disk. Once the crypto volume is unlocked, the boot loader proceeds to load /etc/boot.conf and typically the kernel from the 'a' partition there. The important points to remember are: * boot(8) is stored unencrypted. This should be kind of obvious because it contains the code required to access the softraid volume. * A passphrase or key disk are required BEFORE /etc/boot.conf is read. Softraid crypto is intended to guard against cases where your laptop is stolen, or you send it in for repair, or you throw away the disk. If you expect an attacker to be able to repeatedly access the encrypted data or to modify disk contents, you're in trouble. Apart from the subverted boot loader you are worried about, there are fundamental concerns about the ability of XTS encryption to defend against such attacks. Google keywords: XTS malleability. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: etherip problem
etherip0 and bridge0 were not up. I added the up keyword into /etc/hostname.bridge0 and /etc/hostname.etherip0. Thanks to Pierre. Now, I can see traffic crossing the etherip tunnel. But ARP is still not fully working. I investigate... 2017-02-03 15:11 GMT+01:00 jean-yves boisiaud < jean-yves.boisi...@alcor-consulting.fr>: > hello, > > i'm trying to set an etherip bridge between two OBSD VM which are inside > two ESXi servers. > > I configured bridges and etherip interfaces as said in manual etherip(4). > > private lan1 - host1 host2 - private lan2 > > host1 public address : vmx0, 10.91.178.3 > host2 public address : vmx0, 10.91.219.52 > > private lan1 address and private lan2 address are on vmx1 â > > âfrom host1, I can ping host2 (ping â10.91.219.52) : ok > but, from another host in private lan1 (192.168.33.1), I cannot ping > another host in private lan2 (192.168.33.2). > > I can see arp requests on host1 vmx1, but there is no traffic on bridge0, > neither on etherip0 or vmx0. > > I do not see what is wrong in my configuration. > > Thank you for your help. > > on host1 : > > OpenBSD 6.0 > > sysctl net.inet.ip.forwarding net.inet.etherip.allow > net.inet.ip.forwarding=1 > net.inet.etherip.allow=1 > > ifconfig vmx0 > vmx0: flags=8b43 > mtu 1500 > lladdr a0:36:9f:c0:05:b8 > index 1 priority 0 llprio 3 > media: Ethernet autoselect (10GbaseT) > status: active > inet 10.91.178.3 netmask 0xff80 broadcast 10.91.178.127 > > ifconfig vmx1 > vmx1: flags=8b43 > mtu 1500 > lladdr 00:0c:29:15:34:56 > index 2 priority 0 llprio 3 > media: Ethernet autoselect (10GbaseT) > status: active > inet 192.168.33.254 netmask 0xff00 broadcast 192.168.33.255 > > ifconfig etherip0 > etherip0: flags=8902 mtu 1500 > lladdr fe:e1:ba:d0:7e:f0 > index 6 priority 0 llprio 3 > groups: etherip > media: Ethernet autoselect > status: active > tunnel: inet 10.91.178.3 -> 10.91.219.52 > > ifconfig bridge0 > bridge0: flags=0<> > index 7 llprio 3 > groups: bridge > priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto > rstp > designated: id 00:00:00:00:00:00 priority 0 > etherip0 flags=3 > port 6 ifpriority 0 ifcost 0 > vmx1 flags=3 > port 2 ifpriority 0 ifcost 0 > Addresses (max cache: 100, timeout: 240): > > -- > Jean-Yves Boisiaud - Alcor Consulting > 24, rue de la Glycine > 49250 Saint Remy la Varenne > mobile : +33 6 63 71 73 46 <+33%206%2063%2071%2073%2046> fixe : +33 9 72 > 41 19 35 <+33%209%2072%2041%2019%2035> > -- Jean-Yves Boisiaud - Alcor Consulting 24, rue de la Glycine 49250 Saint Remy la Varenne mobile : +33 6 63 71 73 46 fixe : +33 9 72 41 19 35
HEADS UP: pkg_add supports installpath
just committed, will be in the next series of snapshots. so, basic installs create /etc/installurl now, pkg_add uses it "by default" to create an installpath. pkg.conf(5) takes precedence (user defines are stronger than automatic defines): installpath = anything in pkg.conf will replace the installpath value from installurl. So, if you had an install that created /etc/installurl, and if you want pkg_add to take advantage of it, you will have to remove the installpath line you had in pkg.conf (note that you can comment it out if you're unsure whether your pkg_add supports installurl).
Re: Spammer whitelisted by spamd. How?
Op Sat, 04 Feb 2017 10:03:02 +0100 schreef Clint Pachl : Can someone explain how the spammer at 81.7.16.33 got white listed by spamd and delivered 3 spam emails to me? What exactly triggered the white listing? I may not understand spamd's behavior, but according to the spamd log below, the spammer attempted only 5 deliveries via spamd, each with a different envelope-from address. Correct? At 17:12 there is a 6th connection. Presumably this is a re-try of one of the existing grey entries. With -v you would have seen something like: Feb 3 17:12:29 zeus spamd[34374]: (GREY) 81.7.16.33: -> /B If so, shouldn't white listing be considered only if, during passtime, the retries from a GREY host contain the same envelope-from and envelope-to? Legitimate mail would be resent with the same envelope-from/-to, but spammers (this one in particular) often do not. Ensuring consistent envelope addresses may be a way to stop more spam. No? # passtime set short as I'm currently experimenting $ rcctl get spamd | grep flags spamd_flags=-G 1:10:1080 $ fgrep 81.7.16.33 /var/log/spamd Feb 3 16:58:27 zeus spamd[34374]: 81.7.16.33: connected (3/1) Feb 3 17:00:05 zeus spamd[21625]: new entry 81.7.16.33 from to , helo minyu1esc.com Feb 3 17:00:10 zeus spamd[34374]: 81.7.16.33: disconnected after 103 seconds. Feb 3 17:06:50 zeus spamd[34374]: 81.7.16.33: connected (3/2) Feb 3 17:07:10 zeus spamd[21625]: new entry 81.7.16.33 from to , helo minyu1esc.com Feb 3 17:07:10 zeus spamd[34374]: 81.7.16.33: disconnected after 20 seconds. Feb 3 17:07:47 zeus spamd[34374]: 81.7.16.33: connected (3/2) Feb 3 17:08:00 zeus spamd[21625]: new entry 81.7.16.33 from to , helo minyu1esc.com Feb 3 17:08:02 zeus spamd[34374]: 81.7.16.33: disconnected after 15 seconds. Feb 3 17:08:28 zeus spamd[34374]: 81.7.16.33: connected (4/3) Feb 3 17:08:41 zeus spamd[21625]: new entry 81.7.16.33 from to , helo minyu1esc.com Feb 3 17:08:41 zeus spamd[34374]: 81.7.16.33: disconnected after 13 seconds. Feb 3 17:10:22 zeus spamd[34374]: 81.7.16.33: connected (4/3) Feb 3 17:10:39 zeus spamd[21625]: new entry 81.7.16.33 from to , helo minyu1esc.com Feb 3 17:10:39 zeus spamd[34374]: 81.7.16.33: disconnected after 17 seconds. Feb 3 17:12:13 zeus spamd[34374]: 81.7.16.33: connected (5/4) Feb 3 17:12:29 zeus spamd[34374]: 81.7.16.33: disconnected after 16 seconds. Feb 3 17:12:50 zeus spamd[17428]: queueing add of 81.7.16.33 Feb 3 17:12:50 zeus spamd[17428]: whitelisting 81.7.16.33 in /var/db/spamd -- Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
how to generate sha512 password hashes for Linux on OpenBSD?
Hi,
how could I generate sha512 password hashes for Linux on OpenBSD?
Using 'crypto' from Python is no go, as this is OS dependent. So I
tried following via passlib but it does not work, ie. I can't login on EL7.
~~~
#!/usr/bin/python2.7
from passlib.hash import sha512_crypt
import getpass
hash = sha512_crypt.using(salt_size=16).encrypt(getpass.getpass())
# XXX
# print(hash)
hl = hash.split("$",3)
print("$6$%s" % hl[3])
~~~
It does add 'rounds=656000$', so removing this is needed.
On EL7 with hash from above:
echo
'userfoo:$6$1AfrAnSyjs7Xpki7$59aX53IQcu9JRZKdHT311HOurgVftM/5RlgOrz7fFlDcQEqhcoUCvuDeXyMogTQrvwtmWE8Tnr2vhV2Jf2aqq0'
\
| chpasswd -e
And try ssh as 'userfoo'.
What can I do wrong? What is your way to generate it on OpenBSD?
j.
Re: pkg_add: ftp: connect: Invalid argument
On Sat, Feb 04, 2017 at 08:31:45PM -0800, jungle boogie wrote: > On 02/04/2017 05:45 PM, Philip Guenther wrote: > >On Sat, 4 Feb 2017, jungle boogie wrote: > >>What's happening here? > >> > >>$ doas pkg_add -u > >>Error from http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ > >>ftp: connect: Invalid argument > > > >Running that under ktrace -i might help see the problem, ala > > doas ktrace -i pkg_add -u > > > >then kdump | less and look for a failed connect call. Should be able to > >search for "connect -1 errno" and then go backwards to see the connect() > >call and the sockaddr passed to it. > > > > > > Here's where it actually lits the URL: perl doesn't do network connects in that context. just run ftp -o - http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ it should dump the html list of packages. if it doesn't, your network is broken.
Re: Memory alignment
On Fri, Feb 03, 2017 at 04:07:25PM +0100, Boudewijn Dijkstra wrote:
> Op Sat, 28 Jan 2017 06:26:16 +0100 schreef Damian McGuckin
> :
> > What is the recommended most portable way to force memory alignment for
> > a datum of any type, assuming one has a pointer say
> >
> > char *x
> >
> > I currently use something like
> >
> > char *xany = aligntonext(x, sizeof(long))
> >
> > where I use my own function 'aligntionext' which is defined below and I
> > also assume that a 'long' will be the natural word-size of the machine
> > and that any datum things just needs to align to this boundary. That
> > said, if the second argument is say 4k, the function will align its
> > result to a 4k boundary.
> >
> > I was wondering if there is an optimal, better, more acceptable, or more
> > portable, way.
> >
>
> Easy and very portable:
>
> void *
> aligntonext(void *x, size_t size)
> {
> return (void *)uintptr_t)x + size - 1u) / size) * size);
> }
>
> Whether it is optimal depends on compiler optimization.
Isn't this stuff macros are made of:
# define aligntonext(ptr, size) \
((void*)uintptr_t)(ptr) + (size) - 1u) / (size)) * (size)))
Or
# define aligntonext(ptr, bits) \
((void*)uintptr_t)(ptr) + (1<<(bits)) - 1u) >> (bits)) << (bits)))
Note that the second argument is evaluated three times in both variants...
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: How boot HDD-side crypto softraid from (bootable) USB disk? (AMD64/ARM. Currently installboot fails with "cross-device install"!..)
Perhaps I should point out that the only reason I suggested installing OpenBSD on the stick here was for recovery purposes, and for installing the boot loader. The boot loader allows you to select the HDD you have at the start. So edit /etc/boot.conf *on the stick* as follows: boot sr0a:/bsd That should do the trick. On your softraid volume is your plain, normal OpenBSD install (similar to how it would be installed on a non-softraided partition). No trickery needed there, and no need to store the "b" partition somewhere else either, its fine on the softraid partition. On Mon, 06 Feb 2017 05:17:22 + Tinker wrote: > On 2017-02-06 11:40, bytevolc...@safe-mail.net wrote: > > There is still an elephant in the room. > > > > What if someone has physical access to your machine's USB ports, and > > decides to boot something nasty from it, which in turn modifies the > > firmware in your system (very likely to be possible due to stupid > > "consumer-grade" junk like UEFI or OS-flashable BIOS without > > hardware write protection). > > > > This infected firmware can then scan through any keys that you > > input, including the USB key disk, and the security of this > > 'softraid "firewall"' is now compromised. > > Right, booting off USB provides no protection against physical > attacks and nor against broken firmware.
Re: Memory alignment
Op Sat, 28 Jan 2017 06:26:16 +0100 schreef Damian McGuckin
:
What is the recommended most portable way to force memory alignment for
a datum of any type, assuming one has a pointer say
char *x
I currently use something like
char *xany = aligntonext(x, sizeof(long))
where I use my own function 'aligntionext' which is defined below and I
also assume that a 'long' will be the natural word-size of the machine
and that any datum things just needs to align to this boundary. That
said, if the second argument is say 4k, the function will align its
result to a 4k boundary.
I was wondering if there is an optimal, better, more acceptable, or more
portable, way.
Easy and very portable:
void *
aligntonext(void *x, size_t size)
{
return (void *)uintptr_t)x + size - 1u) / size) * size);
}
Whether it is optimal depends on compiler optimization.
--
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Re: How boot HDD-side crypto softraid from (bootable) USB disk? (AMD64/ARM. Currently installboot fails with "cross-device install"!..)
On 2017-02-06 08:40, bytevolc...@safe-mail.net wrote: Perhaps I should point out that the only reason I suggested installing OpenBSD on the stick here was for recovery purposes, and for installing the boot loader. The boot loader allows you to select the HDD you have at the start. So edit /etc/boot.conf *on the stick* as follows: boot sr0a:/bsd That should do the trick. On your softraid volume is your plain, normal OpenBSD install (similar to how it would be installed on a non-softraided partition). No trickery needed there, and no need to store the "b" partition somewhere else either, its fine on the softraid partition. Ah dear, there are more block devices in the booat loader than "hd", is that in any man page anywhere?? Thanks for bringing up. Now, what you suggest, is it: On the USB stick, create two BSD partitions: one for the crypto keydisk, and one being a softraid, with one partition in it, being an UFS filesystem with /boot and /etc/boot.conf , with the line "boot sr0a:/bsd" in it? But wouldn't the sr0 be the boot softraid then - and the HDD softraid be sr1? Please clarify the utility and how to do it. Thanks, Tinker
