Re: syslog-ng on OpenBSD 5.9

[Nathan Wheeler]

With the changes in 5.6 using sendsyslog(2), only syslogd picks up
local syslog. Search the openbsd-ports list for syslog-ng to see some
comments on it.

Re: Unable to sufficiently clean up softraid metadata

[Nathan Wheeler]

I have a similar sort of setup during installs and I clear out the
first 10m before setting up the CRYPTO disk and it works for me. I
don't think you're zeroing out enough at the beginning of the disk.

dd if=/dev/zero of=/dev/rsd0c bs=10m count=1

On Tue, Dec 1, 2015 at 4:33 PM, Patrik Lundin  wrote:
> On Wed, Dec 02, 2015 at 01:26:10AM +0100, Patrik Lundin wrote:
>>
>> I have a custom installer script which automatically creates RAID
>> devices and assembles an sd1 CRYPTO device before the ordinary installer
>> continues (making the installer use sd1 for the rest of the
>> installation).
>>
>
> I forgot to mention this on OpenBSD 5.8.
>
> --
> Patrik Lundin

Re: Mixing auto_install with softraid0 hdd encryption

[Nathan Wheeler]

On Fri, Nov 13, 2015 at 4:37 PM, szs  wrote:
> I have been playing around with auto_install today, hugely satisfying seeing
> your system install in less than two mins!
>
> I wondering if anyone has any experience mixing this with disk encryption with
> bioctl?
>
> I'm thinking that it may take some hacking about with bsd.rd but I am not sure
> where to start.

I use autoinstall(8) with a CRYPTO disk and yes I compile my own
bsd.rd to do it. You can start by looking at install.sh in
src/distrib/miniroot.

> Does anyone have tips on how I could pass instructions to 'bioctl' and whether
> or not an encrypted hash of the password (such as with 'encrypt -b 8 password'
> could be fed into this and work?

For bioctl you'll probably want to use "-s" to read the passphrase
from stdin. You can't feed it a hash, it will just use that hash as
the actual passphrase.

Re: installboot with amd64 root on softraid crypto, NOT 'a' partition

[Nathan Wheeler]

I ran into this exact same issue when I was trying to create a
rollback install with CRYPTO for a sort of appliance I develop/manage
for my company. We only have remote access with console and remote
hands aren't easy to get so when upgrading it'd be nice to have a
rollback in case something happens.

You can definitely boot a kernel off a different partition, but the
kernel still assumes the root disk is 'a'. You have to tell the kernel
to ask you for the root partition with "boot -a". Or you can compile
your own kernel with the root disk hardcoded as it mentions in this
post: http://www.undeadly.org/cgi?action=article=20110530221728

But I've come to the same conclusion that most people would say on
this list that its just not a good idea. I definitely don't plan to
put that practice in production. But if its just a personal use
laptop, maybe it'll be OK, up to you.

Re: OpenBSD + OptiPlex 320 = frozen clock?

[Nathan Wheeler]

Try changing the value for the sysctl variable
kern.timecounter.hardware? Its just a guess, but its helped me when
I had problems with the clock before.

On Fri, Jan 2, 2015 at 7:47 AM, John Merriam j...@johnmerriam.net wrote:
 Hello.  I have a strange issue with OpenBSD on my Dell OptiPlex 320.  The
 clock doesn't move:

 # date; sleep 55; date
 Thu Jan  1 02:25:47 EST 2015
 Thu Jan  1 02:25:47 EST 2015

 I see the same behavior with 5.6-release amd64 and -current amd64.  The
 clock works fine in Windows and Linux on this machine.  I installed the
 December 27th snapshot on it so I can mess around with it and try to get it
 fixed.  Has anyone seen this before?  If not, any tips on what to try or
 where I should start looking in the code to try to figure out what's going
 on?

 Below is the dmesg:

 OpenBSD 5.6-current (GENERIC.MP) #735: Sat Dec 27 13:55:58 MST 2014
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
 real mem = 3437608960 (3278MB)
 avail mem = 3342295040 (3187MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0450 (68 entries)
 bios0: vendor Dell Inc. version 1.1.12 date 06/17/2009
 bios0: Dell Inc. OptiPlex 320
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S1 S3 S4 S5
 acpi0: tables DSDT FACP SSDT APIC BOOT MCFG HPET SLIC SSDT SSDT SSDT
 acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI7(S5) MAC1(S5) MOU_(S3) USB0(S3)
 USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: Intel(R) Core(TM)2 Duo CPU E4400 @ 2.00GHz, 2000.36 MHz
 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,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
 cpu0: 2MB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
 cpu0: apic clock running at 200MHz
 cpu0: mwait min=64, max=64, C-substates=0.2.2.0.0, IBE
 cpu1 at mainbus0: apid 1 (application processor)
 cpu1: Intel(R) Core(TM)2 Duo CPU E4400 @ 2.00GHz, 2000.08 MHz
 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,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF
 cpu1: 2MB 64b/line 8-way L2 cache
 cpu1: smt 0, core 1, package 0
 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 21, 24 pins
 ioapic0: misconfigured as apic 0, remapped to apid 8
 acpimcfg0 at acpi0 addr 0xe000, bus 0-255
 acpihpet0 at acpi0: 14318180 Hz
 acpiprt0 at acpi0: bus 1 (PCI1)
 acpiprt1 at acpi0: bus -1 (PCI2)
 acpiprt2 at acpi0: bus -1 (PCI3)
 acpiprt3 at acpi0: bus -1 (PCI4)
 acpiprt4 at acpi0: bus -1 (PCI5)
 acpiprt5 at acpi0: bus -1 (PCI6)
 acpiprt6 at acpi0: bus -1 (PCI8)
 acpiprt7 at acpi0: bus 2 (PCI7)
 acpiprt8 at acpi0: bus 0 (PCI0)
 acpicpu0 at acpi0: PSS
 acpicpu1 at acpi0: PSS
 acpibtn0 at acpi0: VBTN
 cpu0: Enhanced SpeedStep 2000 MHz: speeds: 2000, 1600, 1200 MHz
 pci0 at mainbus0 bus 0
 0:20:0: mem address conflict 0xfed0/0x400
 pchb0 at pci0 dev 0 function 0 ATI RC410 Host rev 0x01
 ppb0 at pci0 dev 1 function 0 ATI RS480 PCIE rev 0x00
 pci1 at ppb0 bus 1
 radeondrm0 at pci1 dev 5 function 0 ATI Radeon XPRESS 200 rev 0x00
 drm0 at radeondrm0
 radeondrm0: apic 8 int 17
 ahci0 at pci0 dev 18 function 0 ATI SB600 SATA rev 0x00: apic 8 int 23,
 AHCI 1.1
 scsibus1 at ahci0: 32 targets
 sd0 at scsibus1 targ 0 lun 0: ATA, WDC WD5000AACS-0, 05.0 SCSI3 0/direct
 fixed naa.50014ee201ce1451
 sd0: 476940MB, 512 bytes/sector, 976773168 sectors
 cd0 at scsibus1 targ 1 lun 0: PBDS, CDRWDVD DH-48C2S, ND11 ATAPI 5/cdrom
 removable
 ohci0 at pci0 dev 19 function 0 ATI SB600 USB rev 0x00: apic 8 int 16,
 version 1.0, legacy support
 ohci1 at pci0 dev 19 function 1 ATI SB600 USB rev 0x00: apic 8 int 17,
 version 1.0, legacy support
 ohci2 at pci0 dev 19 function 2 ATI SB600 USB rev 0x00: apic 8 int 18,
 version 1.0, legacy support
 ohci3 at pci0 dev 19 function 3 ATI SB600 USB rev 0x00: apic 8 int 17,
 version 1.0, legacy support
 ohci4 at pci0 dev 19 function 4 ATI SB600 USB rev 0x00: apic 8 int 18,
 version 1.0, legacy support
 ehci0 at pci0 dev 19 function 5 ATI SB600 USB2 rev 0x00: apic 8 int 19
 usb0 at ehci0: USB revision 2.0
 uhub0 at usb0 ATI EHCI root hub rev 2.00/1.00 addr 1
 piixpm0 at pci0 dev 20 function 0 ATI SBx00 SMBus rev 0x13: SMI
 iic0 at piixpm0
 spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5
 spdmem1 at iic0 addr 0x51: 2GB DDR2 SDRAM non-parity PC2-5300CL5
 pciide0 at pci0 dev 20 function 1 ATI SB600 IDE rev 0x00: DMA, channel 0
 configured to compatibility, channel 1 configured to compatibility
 azalia0 at pci0 dev 20 function 2 ATI SBx00 HD Audio rev 0x00: apic 8 int
 16
 azalia0: codecs: Analog Devices AD1983
 audio0 at azalia0
 pcib0 at pci0 dev 20 function 3 ATI SB600 ISA 

Stop console logging during install

[Nathan Wheeler]

I'm trying to create an appliance like install and want to stop
logging to console. So this is during the install process, not a
normally running machine. I know this is very useful information, but
this would definitely be nice to disable for a bit.

In particular when running bioctl to setup a softraid device with
CRYPTO, console outputs a new disk is attached, but I don't want this
to show.

My guess is a boot option but I've looked around a lot and can't find
a way. Coming to the conclusion that I'll need to edit and compile the
kernel to turn that off, but I hope not.

Thanks

Re: Hide VM data from customer

[Nathan Wheeler]

Eric, thats an interesting way to do it. Though I think it would take
more changes in the system than we'd like to implement.

I was actually able to get full disk encryption to work without
entering the passphrase. I edited softraid.c
(http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/libsa/softraid.c)
and hardcoded a passphrase so instead of prompting for it, it will
automatically try the hardcoded passphrase. I compiled the second
stage boot file and applied it with installboot like normal to the
encrypted disk. The system boots with no manual intervention to an
encrypted disk. Its some decent obfuscation to keep curious eyes out.

Doing this seems kinda hokey so I'm not sure we'll go this route, but
it does give us an option at least.

On Tue, Dec 9, 2014 at 4:55 PM, Eric Lalonde eric.c.lalo...@gmail.com wrote:
 One of the services provided by a previous employer was to on-premise 
 appliance for customers, rented in a SAAS model. Customers paid for a certain 
 amount of disk space. To ensure they couldn’t just swap disks to add more 
 capacity, each of our disks went through a ‘blessing’ process where we 
 performed various interesting perturbations to the first few megs of every 
 disk, including a checksum that was a function of a machine and customer 
 identifier.

 We fully understood that these efforts would never get in the way of a 
 dedicated and sophisticated adversary, but the bar was low since most of the 
 customers were end users who were using a managed service provider and never 
 directly interacted with our appliance.

 You might want to try something like that to make it non-trivial for 
 customers to pull your data.

 - Eric

 On Dec 9, 2014, at 4:14 PM, Steve Shockley steve.shock...@shockley.net 
 wrote:

 On 12/9/2014 2:38 PM, John Merriam wrote:
 Oh, and no matter what you do, they could always dump the RAM from your VM
 instance and get your data from there after it's been decrypted.

 The key is also likely stored in RAM, and it is simpler to get a snapshot of 
 RAM from a VM than it is to get one from a physical machine.

Re: Hide VM data from customer

[Nathan Wheeler]

Tim, I didn't even think about just using another disk. That's the
simpler solution by far, but does come with some drawbacks. A very
small partition or disk by itself is pretty conspicuous, and wouldn't
be very hard to figure out what its for.

It also does make our install a bit more complex. We have standard
hardware we use with only one drive and I'd rather not have to
maintain a VM image and a physical image. So we'd have to use the
partition as a key method which will mean maintaining code again for
now.

Another option I have at least though! Thanks!

On Wed, Dec 10, 2014 at 8:42 AM, trondd tro...@gmail.com wrote:
 What about using a kay partition local to the VM disk
 http://marc.info/?l=openbsd-miscm=141435482820277w=2

 You'd be maintaining code either way, though.

 Or add an additional disk to the VM that is the keydisk.

 Tim.

Hide VM data from customer

[Nathan Wheeler]

Hi everyone,

We use OpenBSD currently on physical hardware and manage it in our
customers location. We want the option to give out VMs to host on
customer premises and we'll still manage the VM (but not the VM
platform).

The problem is not letting the customer access to our proprietary data
as they could easily mount the virtual hard drive somewhere else. The
obvious answer is disk encryption, but we can't require manual
intervention to enter a passphrase or to provide a key.

I'm sure I'll have to settle with obfuscation, which I'm OK with, but
I'm curious if there is a good/best way to go about that.

Is the only option to change things we need to hide into binaries?
Compile the kernel with a key to decrypt?

I've taken a look at how other vendors do it like Juniper. With their
VM I can mount the boot partitions, but they only have boot
information and the kernel. I can't mount the extended partitions,
they don't even seem to be formatted with a filesystem. My guess is
they compile the kernel with a key or something, but its just a guess.

Thanks for any advice!

Nate

Re: Hide VM data from customer

[Nathan Wheeler]

Thank John! Sounds like the best way is to compile a key into a binary
and decrypt partitions or files that way.

I'm certain obfuscation is my only real option without manual
intervention, and I'm OK with that. I know it won't actually be
secure. Mostly I just want to stop curious eyes, I don't need to stop
someone really determined.

I just want to make sure there isn't some standard way to obfuscate
partitions/data in VMs used as appliances.

On Tue, Dec 9, 2014 at 11:38 AM, John Merriam j...@johnmerriam.net wrote:
 On Tue, 9 Dec 2014, Nathan Wheeler wrote:

 Hi everyone,

 We use OpenBSD currently on physical hardware and manage it in our
 customers location. We want the option to give out VMs to host on
 customer premises and we'll still manage the VM (but not the VM
 platform).

 The problem is not letting the customer access to our proprietary data
 as they could easily mount the virtual hard drive somewhere else. The
 obvious answer is disk encryption, but we can't require manual
 intervention to enter a passphrase or to provide a key.

 I'm sure I'll have to settle with obfuscation, which I'm OK with, but
 I'm curious if there is a good/best way to go about that.

 Is the only option to change things we need to hide into binaries?
 Compile the kernel with a key to decrypt?

 I've taken a look at how other vendors do it like Juniper. With their
 VM I can mount the boot partitions, but they only have boot
 information and the kernel. I can't mount the extended partitions,
 they don't even seem to be formatted with a filesystem. My guess is
 they compile the kernel with a key or something, but its just a guess.

 Thanks for any advice!

 Nate


 You said that you are already letting your proprietary data out in the
 wild since you have machines on customer premises with this data in
 unencrypted form.  If it moves from a physical machine to a virtual one it
 is true that it makes it easier for someone to access it but not that much
 easier.

 Anyway, the way I see it, the only way to keep someone from accessing your
 data is encryption.  Obfuscation alone will make it harder but not
 impossible.

 To avoid manual intervention when using encryption you need a way to get
 the key/passphrase to the machine/application.  If you were using
 application/file level encryption, you could compile the key in to a
 binary application that would then work with the data.  That is still
 obfucation to an extent because they could still decompile the binary and
 find your key.

 Another option I just thought of is if you coded your application that
 accesses the data to download (over an encrypted connection of course...)
 the key from a server that you control at your location that the
 application would then use to decrypt the data.

 If you wanted to use FDE without manual intervention you would need to
 modify the OS source to find the key somewhere (unallocated sectors at the
 end of the disk or between partitions?) that it could access before it
 tries to decrypt the partition.  Obfuscation again.  But pretty well
 obfuscated.

 Another thing you could do is have a separate partition that is not the
 boot partition (like /data) that is encrypted and have the boot scripts
 decrypt and mount the partition.  You would need to cary around the
 passphrase/key on the unencrypted boot partition though.  Obfuscaction
 again (but maybe you could combine this with downloading the key/pass
 from a server of yours?).

 The only thing I mentioned that doesn't involve obfuscation or manual
 intervention is coding an/your application that will download the key from
 a server to decrypt the data that has been encrypted.  You would need to
 use something like HTTPS with username/password or SCP to transfer the
 key.  The server serving the key should have access to it restricted by
 IP.  Oh, but wait, they could still get the key if they decompile the
 program that downloads the key and do exactly what it does.  Hmmm, still
 obfuscation I guess.

 Oh, and no matter what you do, they could always dump the RAM from your VM
 instance and get your data from there after it's been decrypted.

 So, yeah, no really good answer that I know of.  I'm not an expert in
 areas such as this, but this is the way I see it.  Your best bet is
 probably encryption combined with some good obfuscation as to what the key
 is/where to get it.  Not moving your data to a VM would make some of these
 attacks harder but not impossible for a determined attacker.

 --

 John Merriam