Re: [SPAM?] OpenBSD's experience with writing secure c/c++ code.

[Kevin Chadwick]

On Fri, 10 Sep 2021, 08:56 Martin Schröder,  wrote:

> Am Do., 9. Sept. 2021 um 15:03 Uhr schrieb el3ctr0lyte
> :
> > Rust totes itself as a systems programming language that promises memory
> safety and so far it seems to deliver on that promise. I was just
> wondering, what are your opinions on Rust and do you guys think it is a
> worth while language to learn. You have a lot of experience with writing
> secure code in C/C++ and this is why i am asking. What is your experiences
> like in this area?
>
> It took me three clicks to find this mail from Theo:
> https://marc.info/?l=openbsd-misc&m=151233345723889&w=2
>
> What have you done but distract OpenBSD's developers?
>

Ada has a better chance with less compile time and is more secure than Rust
actually, but then it's had a FSF compiler for many years with noone
writing tools. So I wouldn't be too hopeful.

Unfortunately it's compiler is also GPL with an exemption 😔

It would be strange if tools were written in Rust for Linux when Ada has
been there, all these years. Of course, systemd happened.

>

Re: Rationale behind exec clearing out unveil paths

[Kevin Chadwick]

On 6/15/21 4:33 PM, dz...@disroot.org wrote:
>  If it only needs access to its lock file,
> why should I give it access to my ssh keys?

I think that it is worth understanding that you can use file and process
permissions, for that.

Unveil is an extra layer, because no matter what ssh key you provide to an
unveiled app. The developer of that application can decide that I only need
access to a particular key provided on the command line and only within certain
execution paths.

The app design may have a separate process that just handles the key and limited
operations by talking via a socket. In a way, accomplishing that which you
wanted in the first place. Possibly without you the user, even knowing.

sysupgrade reset option

[Kevin Chadwick]

I am likely going to simply track file changes and revert them for a reset to
factory defaults facilitation, rather than maintaining a build system for a
custom bsd.rd.

One assumption that I have made is that newfs and dd altroot to root and reboot
in rc.securelevel would fail or be problematic?

Is there any chance that OpenBSD would be interested in patches to add an
unattended install option similar to how an auto_upgrade.conf is detected but
where an /auto_install.conf is detected? I believe that the current autoinstall
procedure requires interactivity (A) key or netboot.

Re: iwm(4): Tx aggregation

[Kevin Chadwick]

On 4/30/21 12:18 PM, Stefan Sperling wrote:
> Our default group cipher is CCMP which should not involve any TKIP MIC
> checks on the AP. Such checks occuring would be a bug in this case.

TKIP has been so easily crackable for over a decade that I wonder if it has a
place in OpenBSD, atleast without stark warnings.

Is it worth the maintenance?

Re: iwn: fix hangs with Tx aggregation

[Kevin Chadwick]

On 3/16/21 2:38 PM, Stefan Sperling wrote:
> However, the second frame was sent at 24 Mbit/s, which
> indicates that the firmware could be retrying the BA request (frames sent
> at a different Tx rate than specified by the driver are generally retries).

My guess would be that a CRC fails causing a retransmission due to low signal
bit corruption. Though I would expect a retransmission of an exact copy, 
strange.

Re: Destructive Install Process (fdisk)

[Kevin Chadwick]

On 2020-06-25 20:16, Theo de Raadt wrote:
> I'd say that I simply don't see why the installer destructively 
> re-arranges the disk's scheme prior to officially choosing to write
> the new partitioning scheme to the disk.

I'm not sure that I believe that and it shows you what YOU are about to commit!

AFAIK grub is called grub for a reason. In that it needed more disk space than
the MBR offered. IOW grub is far more destructive than OpenBSD or the Windows
installer. The fact that Linux distros detect and fix that destruction doesn't
change that. In my experience (less GPT), it is far easier to install Windows
after OpenBSD and get both working again than installing Windows after
installing Grub/Linux.

Re: [PATCH] pledge: allow kern.somaxconn sysctl for inet

[Kevin Chadwick]

For the archives, if anyone else hits this issue.

Being killed with pledge sysctl 2 on a golang http.ListenAndServe, no longer
happens.

https://github.com/golang/go/issues/31927

Re: WireGuard patchset for OpenBSD

[Kevin Chadwick]

On 2020-05-12 10:00, Jason A. Donenfeld wrote:
> Djb has a nice post on chacha performance in
> this context: .

I shall leave this to the wireguard folks to explore but I'm not totally
convinced. It is not just about speed.

Perhaps Intel chips are different or perhaps DJB is biased towards use of his 
code?

In my experience with small 4mm processors that have hw AES support. The CPU is
basically idle and can sleep or able to do whatever it wants whilst awaiting for
the AES peripheral to finish a block and 10 times faster than software.

These processors are a few pounds and do a lot of other things, so for DJB to
say hw AES is expensive for Intel? Perhaps it is true on FISC chips with much
higher mhz/throughput requirements.

Re: WireGuard patchset for OpenBSD

[Kevin Chadwick]

On 2020-05-12 06:05, Matt Dunwoodie wrote:
>  I don't want to put misleading numbers out there and every use case
>is different, therefore you should perform your own tests. In my
>environment (tcbbench between two Lenovo x230 (i5-3320m), em(4)
>ethernet) I was seeing 750mbit/s. This was compared to default
>isakmpd(8) with a basic ike psk configuration, which achieved
>380mbit/s. Different configurations will behave differently, of
>course, but I think we're off to a pretty good start here.

That is certainly more than fast enough for my purposes and at slower speeds
will cause no issue with the bonus that hw that does not have AES-NI, will still
be performant.

However I assume that compared to using AES-NI, the machine will be running a
lot hotter, using more power and be less usable for other tasks.

Especially, less powerful systems will have far less performance when their hw
support is not utilised and contrary to the wireguard paper. Many embedded
systems do have AES hw support.

I imagine supporting all those embedded hw variants is problematic and part of
the reason AES might have been avoided?

I just wonder. Is there scope in the design for adding AES-NI support, in the
future as a config option even, rather than a runtime negotiation like OpenSSH
facilitates?

Re: iwn/athn/wpi: fix CCMP replay check with HW crypto

[Kevin Chadwick]

On 2020-05-01 16:05, Stefan Sperling wrote:
>  The CCMP header contains a nonce,
> which is incremented by the transmitter whenever it encrypts a new frame.

I assume there isn't opportunity to set the nonce to a 128 bit random one. It
would avoid a lot of risk with the likelihood of collisions being
probalistically guaranteed in all circumstances, rather than absolutely
guaranteed to avoid collisions, in some?

Re: [PATCH] sysupgrade

[Kevin Chadwick]

>> Struggling to remember why I wanted to do it, to be honest.
>
>Because until relatively recently X was installed sgid root. But that
>was fixed for 6.5:
>

That wasn't a factor. You could always mount it nosuid, even noexec anyway.

Re: [PATCH] sysupgrade

[Kevin Chadwick]

On 2020-04-30 03:28, James Jerkins wrote:
> This patch adds two new options to sysupgrade. The first option is for small 
> box systems like an APU system that only has the base and manual sets 
> installed. The second option is for headless systems without X11 like servers.

I used to avoid installing the X sets and I found that even on e.g. a web server
without X11 running. I would end up installing them in the end as certain ports
would require them. Struggling to remember why I wanted to do it, to be honest.
A notion from securing Linux perhaps. As Linux often runs things automatically
when they're installed and desktop distros run a lot by default. It is what is
in RAM, that is more important, which is very little by default on OpenBSD 
(~60M).

May be worth re-considering if it is worth the effort to save a fairly small
amount of space with potentially unexpected consequences?

Re: Some small nits with httpd and relayd and a relayd question

[Kevin Chadwick]

On 2020-04-16 18:34, Kevin Chadwick wrote:
> If httpd is put in front of a reverse proxy of grafana. I seem to get some
> http/1.1 js requests become http/1.0 bad requests.

I should add that this was with httpd fcgi. So it may just be, my bad.

Some small nits with httpd and relayd and a relayd question

[Kevin Chadwick]

If httpd is put in front of a reverse proxy of grafana. I seem to get some
http/1.1 js requests become http/1.0 bad requests.

Perhaps related
"http://daemonforums.org/showthread.php?p=68392";

With relayd there is no problem.

However relayd seems to not like the nistp521 keys that httpd was quite happy 
with.

I get "key size 1128 not support" from relayd

https://cvsweb.openbsd.org/src/usr.sbin/relayd/ssl.c?rev=1.34&content-type=text/x-cvsweb-markup

The tls priv sep is the main reason I am using relayd/httpd, so I am not
complaining about this hack. Gos http server is good but doesn't protect the
key, so well.

I assume switching to RSA, is the only answer? Anything below nistp521 would be
more prone than RSA to quantum attacks, if they ever actually happen anyway.

Or is there a diff for httpd that could be adapted to relayd?

Re: Include /var/www/tmp into base install

[Kevin Chadwick]

On 2020-04-07 17:12, Andrew Grillet wrote:
> For me, the "/var is full" problem can be adequately mitigated by mounting
> a separate partition as /var/tmp.

Does FFS2 have the same disklabel limit on partitions? I guess they are 
unrelated.

Sometimes users may decide which mount points to edit out during install and
/var/tmp gives one more for them to understand if it's a problem moving to /var.

Creating /var/tmp is actually a simpler consideration than removing an OS
provided /var/tmp

On web servers, I have /var/www and /var/www/bin as well as others on mount
points so e.g. /var/www is noexec and optionally read-only. /var/www/tmp is
sometimes mfs.

That many mount points obviously doesn't fit so well generically but permissive
permissions if more mount points were available, might work.

I also wonder why /var/log is not on it's own partition by default. I almost
always create it. I guess for smaller disks, more mount points is a pain?


> More of an issue, although obviously not major - if there are a large
> number of tmp directories, is making sure that they are all
> routinely purged. Yes, I know this is down to careless admin practice, but
> it happened to me earlier this year.

A smaller partition would actually have less inodes by default ffs settings.
Something to consider. No idea if/how ffs2 changes that?

Re: Opportunistic DoT for unwind(8)

[Kevin Chadwick]

> The purpose of unwind is to provide secure DNS services even when
> the available nameservers are broken or filtered like in many hotels.
> To do that, it prefers DNSSEC whenever possible and changes to do
> resolving by itself if needed.
> 
> DNSSEC only offers integrity and authenticity.  To protect
> eavesdropping on the requests in transit, encryption is needed, as
> offered by e.g. DNS over TLS (DoT) and DNS over HTTP (DoT). unwind

Before I jump aboard with DNSSECs failings in mind on my own networks rather
than the mentioned hotel scenario. I believe but I am still not certain that
services like PowerDNS have secure channels to the main primary DNS servers that
apparently do not scale for the rest of us? Otherwise I worry that the network
security target is a more singular centralised target compared to e.g. unbound.

Re: Removing PF

[Kevin Chadwick]

On 4/1/19 3:18 PM, Mateusz Guzik wrote:
> While I support pf removal, I don't think bpf is the way to go.
> 
> FreeBSD just removed their pf [1] so the code is up for grabs and you
> can import it with one weird trick.
> 
> [1] 
> https://lists.freebsd.org/pipermail/svn-src-projects/2019-April/013336.html

lol, did you read the link that you posted

"pf in FreeBSD lags years behind OpenBSD's pf. Remove it. Users are advised to
migrate to ipf."

Why would they replace new pf with old or are you trying to suggest ipf instead
of bpf?

Re: On the matter of OpenBSD breaking embargos (KRACK)

[Kevin Chadwick]

On Tue, 19 Jun 2018 09:30:05 -0600


> >   
> > > ps. Disable Intel Hyper-Threading where not needed, until we all
> > > know more.  
> > 
> > Is it safer to use bsd.sp for the time being?  
> 
> No, a better solution is coming.   And in snapshots already.

Thankyou for enabling us to patch ASAP.

Re: On the matter of OpenBSD breaking embargos (KRACK)

[Kevin Chadwick]

On Fri, 15 Jun 2018 17:28:14 -0600


> ps. Disable Intel Hyper-Threading where not needed, until we all know
> more.

Is it safer to use bsd.sp for the time being?

Re: httpd socket leak - Re: httpd ranges are not liked by freshclam

[Kevin Chadwick]

On Wed, 4 Apr 2018 23:58:05 +0100


> TBH I'd probably just disable range processing like done in
> https://ftp.openbsd.org/pub/OpenBSD/patches/6.0/common/017_httpd.patch.sig
> for now, neither memory exhaustion nor FD leak are particularly
> appealing.

I believe this broke html5 video for atleast some if not all apple
products that in their wisdoom decided a connection not working at all
was better than one that would work even in patchy network
conditions, ;) i.e. no byte range support for video, connection closed.

Re: inteldrm(4) tests needed

[Kevin Chadwick]

On Mon, 15 Jan 2018 01:02:58 +0100 (CET)


> So I'm looking for testers.  I'm especially interested in tests of
> external displays on all sorts of connector types (VGA, DVI, HDMI,
> DP).  It would be really great to get some tests on older stuff with
> (S)DVO.  Please let me know if there are regressions or if this fixes
> things that are currently broken.  But all reports are welcome.
> Please include a dmesg and some information about the display and
> connector type.

I have no time till Thu but can test it on an apollo lake then with DP
and HDMI. Also intending on seeing if inteldrm on apollo lake works with
LVDS fpga conversion to DSI MIPI some time soon. However the wsfb seems
to work (most of the time or maybe with right bios config) which is
good enough for us (seemingly even plays youtube OK fullscreen in
firefox).

Re: [patch] acme-client listen option

[Kevin Chadwick]

On Wed, 6 Dec 2017 13:54:36 +


> On 2017/12/06 14:13, Tim Kuijsten wrote:
> >But I suspect the demand for acme-client on
> > non-webservers will rise and it will feel more like a kludge to
> > configure, start and stop a webserver in those environments.  
> 
> Using HTTP at all for these (even if it's only running temporarily)
> feels like a kludge to me.
> 
> I have some, and some https servers that aren't public access where
> it's still useful to have a certificate (letsencrypt's HTTP checks can
> come from various locations so they can't just be whitelisted).
> I'm using DNS-01 (currently with Kristaps' version of acme-client)
> for those.

Perhaps that is a better way especially if you don't have any web
servers and the server you want one for is more secure than your web
server. I use a web server for my mail server (no big deal considering
STARTTLS) to get the cert and then encrypt it with reop and make it
downloadable so that all the mail server needs is /usr/bin/ftp and
reop. You could use libressl or whatever you like to encrypt or even
scp.

Re: Intel HSUART/8250 LPSS

[Kevin Chadwick]

On Fri, 24 Nov 2017 20:26:02 +0100 (CET)


> This device is based on the same Synopsys Designware "IP" as what's
> found on many ARM SoCs.  Pretty much com(4) compatible but with some
> twists.
> 
> 1. The registers are wider.  Instead of the traditional 1-byte
>registers it has 4-byte registers.  On ARM we use a bus_space hack
>to get around this issue, but I don't think I want to advocate
>replicating that approach for amd64/i386.  Abstracting the register
>access functions is probably the way to go.
> 

I wish I had a 32bit uart on ARM cortex, 16 bit is neither here nor
there, though quite useful in some scenarios ;)

You mean a shifting function with single byte I/O?

> 2. There are additional registers.  It seems that most of these can be
>ignored, but the USR register needs to be poked under some
>circumstances.  See sys/arch/armv7/dev/conm_fdt.c.
> 

Nice, I hadn't actually thought of looking at OpenBSD ARM. I was
looking at:

https://cateee.net/lkddb/web-lkddb/SERIAL_8250_LPSS.html
https://github.com/torvalds/linux/blob/master/drivers/tty/serial/8250/8250_lpss.c

> Also, are you looking at acpi attachment or straight PCI?

I was thinking PCI mainly because It looks like from the dmesg that ACPI
would also require a driver. 

Any thoughts?

Thanks

Intel HSUART/8250 LPSS

[Kevin Chadwick]

I am looking into getting Intel HSUART/8250 LPSS support working. Has
anyone done any work on this out of tree. Or is there anything I should
be aware of.

Thanks

Azalia Apollo Lake Cosmetic Patch

[Kevin Chadwick]

Before realising the motherboard switch was set to i2s and wondering
why I had no codecs I cooked up this patch. Almost entirely
cosmetic, Change it, Take it or leave it, obviously.

Note APPLE comment in azalia_codec.c added simply because quirk
present for CS4206 and CS4208 and so guessed at relevance for 4207.

Thanks


Index: src/sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.238
diff -u -p -u -p -r1.238 azalia.c
--- src/sys/dev/pci/azalia.c22 Sep 2017 06:33:44 -  1.238
+++ src/sys/dev/pci/azalia.c22 Nov 2017 15:42:47 -
@@ -458,6 +458,7 @@ azalia_configure_pci(azalia_t *az)
case PCI_PRODUCT_INTEL_C600_HDA:
case PCI_PRODUCT_INTEL_C610_HDA:
case PCI_PRODUCT_INTEL_BSW_HDA:
+   case PCI_PRODUCT_INTEL_APOLLO_LAKE_HDA:
reg = azalia_pci_read(az->pc, az->tag,
INTEL_PCIE_NOSNOOP_REG);
reg &= INTEL_PCIE_NOSNOOP_MASK;
Index: src/sys/dev/pci/azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.172
diff -u -p -u -p -r1.172 azalia_codec.c
--- src/sys/dev/pci/azalia_codec.c  28 Mar 2017 04:54:44 -  1.172
+++ src/sys/dev/pci/azalia_codec.c  22 Nov 2017 15:45:45 -
@@ -72,6 +72,13 @@ azalia_codec_init_vtbl(codec_t *this)
AZ_QRK_GPIO_UNMUTE_3;
}
break;
+case 0x10134207:
+   this->name = "Cirrus Logic CS4207";
+   if (this->subid == 0x72708086) {/* APPLE_MBA? */
+   this->qrks |= AZ_QRK_GPIO_UNMUTE_0 |
+   AZ_QRK_GPIO_UNMUTE_1;
+   }
+   break;
case 0x10134208:
this->name = "Cirrus Logic CS4208";
if (this->subid == 0x72708086) {/* APPLE_MBA6_1 */
Index: src/sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1825
diff -u -p -u -p -r1.1825 pcidevs
--- src/sys/dev/pci/pcidevs 28 Aug 2017 09:43:18 -  1.1825
+++ src/sys/dev/pci/pcidevs 22 Nov 2017 15:48:08 -
@@ -4557,6 +4557,7 @@ product INTEL CORE7G_U_GT2_2  0x591d  HD G
 product INTEL CORE7G_Y_GT2 0x591e  HD Graphics 615
 product INTEL CORE7G_U_GT3_15W 0x5926  Iris Plus Graphics 640
 product INTEL CORE7G_U_GT3_28W 0x5927  Iris Plus Graphics 650
+product INTEL APOLLO_LAKE_HDA  0x5a98  Apollo Lake HD Audio
 product INTEL 5100_HB  0x65c0  5100 Host
 product INTEL 5100_PCIE_2  0x65e2  5100 PCIE
 product INTEL 5100_PCIE_3  0x65e3  5100 PCIE

Re: xf86-video-intel patch to test

[Kevin Chadwick]

On Sat, 11 Nov 2017 19:57:16 +0100


> But since I don't have much hardware still using the intel driver (we
> switched to modesettings(4) for many devices), I'd like to have this
> tested against the current X server as much as possible.

Not sure if an unknown Intel GD would cause use of the "intel" driver
but in case it does then I thought I should say that the system of the
dmesg I have just sent in also behaved the same (display lost during
boot) on 6.2 release.

Re: Add machdep.lidaction=3 - powerdown laptop upon lid closing

[Kevin Chadwick]

What about powerup? Currently if u boot say an access point and close the
lid to save a watt. I *believe*? you have to wait for sysctl.conf to be
read before closing to avoid sleeping?

Re: My ELFSEC implementation (signed binaries for amd64)

[Kevin Chadwick]

On Fri, 5 May 2017 17:56:11 +0200


> If CMAC's can be truncated then this entire implementation can be
> rewritten to not truncate for 64 bit machines and truncate for 32 bit
> machines.

There is also POLY1305-AES which is a little stronger. The more you
limit failed MAC requests the more you can truncate but obviously only
go as far as you must.

Re: My ELFSEC implementation (signed binaries for amd64)

[Kevin Chadwick]

On Fri, 5 May 2017 14:16:37 +0200


> There was concern about my use of MD5 HMAC's so I 
> took them out.  The ELF header of 32 bit systems is too small to fit
> SHA256 checksums, so I'm leaving it out.

Have you considered CMAC which can be truncated if need be and also
could take advantage of AES acceleration.

Alternatively, signify perhaps.

6.1 crypto/disk slow down

[Kevin Chadwick]

I believe I saw a mention of 6.1 scheduling or I/O being a work in
progress, so this post is simply informational and if you wish me to run
any tests then I can. Otherwise this is not a problem right now though
it has made the daily internal backup into a weekly one.

I am using an old fanless P2 400mhz as it has no Intel management mode
and I like schg e.g. on the root of chroots (admittedly I have been
tempted to upgrade but the reliability of an overnight backup HDD have
desuaded me so far, as any modern fanless system I have is a single
drive machine).

However I guess this meagre cpu has highlighted a performance
degradation in 6.1? Copying between two bioctl encrypted disks is very
slow. I figured, wow, I really need to find the time to get a better
CPU/machine.

However, I have since noticed that an rsync cron job scheduled for early
hours and one that I would not notice existed on 6.0 is now running into
the working day at maximised cpu (albeit, niced to 20).

It's Dmesg follows as perhaps some missing CPU instruction is to blame
as I see few if any screams on the list. I don't mind if the answer is
upgrade the hardware but figured the info may be of use and I shall
wait to upgrade a while in case any tests would help.

Regards, Kc


OpenBSD 6.1 (GENERIC) #291: Sat Apr  1 13:49:08 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 398 MHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,PERF
real mem  = 469254144 (447MB)
avail mem = 447557632 (426MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 08/22/99, BIOS32 rev. 0 @ 0xec800, SMBIOS rev. 2.1 @ 
0xf13e6 (54 entries)
bios0: vendor Compaq version "686T3" date 08/22/99
bios0: Compaq Deskpro
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5, can't enable ACPI
bios0: ROM list: 0xc/0x8000 0xc8000/0x800 0xe/0x8000!
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x02
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0x4400, size 0x40
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x02
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Rage Pro" rev 0x5c
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
xl0 at pci0 dev 13 function 0 "3Com 3c905C 100Base-TX" rev 0x74: irq 11, 
address 00:01:02:a2:78:48
bmtphy0 at xl0 phy 24: 3C905C internal PHY, rev. 6
uhci0 at pci0 dev 15 function 0 "VIA VT83C572 USB" rev 0x61: irq 9
uhci1 at pci0 dev 15 function 1 "VIA VT83C572 USB" rev 0x61: irq 7
ehci0 at pci0 dev 15 function 2 "VIA VT6202 USB" rev 0x63: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "VIA EHCI root hub" rev 2.00/1.00 
addr 1
piixpcib0 at pci0 dev 20 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 20 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA, 38162MB, 78156288 sectors
wd1 at pciide0 channel 0 drive 1: 
wd1: 16-sector PIO, LBA48, 78533MB, 160836480 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
wd2 at pciide0 channel 1 drive 0: 
wd2: 16-sector PIO, LBA, 76293MB, 15625 sectors
atapiscsi0 at pciide0 channel 1 drive 1
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
removable
wd2(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
cd0(pciide0:1:1): using PIO mode 4, DMA mode 2
uhci2 at pci0 dev 20 function 2 "Intel 82371AB USB" rev 0x01: irq 7
piixpm0 at pci0 dev 20 function 3 "Intel 82371AB Power" rev 0x02: SMI
iic0 at piixpm0
spdmem0 at iic0 addr 0x50: 64MB SDRAM non-parity PC100CL3
spdmem1 at iic0 addr 0x51: 128MB SDRAM non-parity PC100CL3
spdmem2 at iic0 addr 0x52: 256MB SDRAM non-parity PC133CL3
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "VIA UHCI root hub" rev 1.00/1.00 
addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "VIA UHCI root hub" rev 1.00/1.00 
addr 1
isa0 at piixpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (49f2d936677afcd0.a) swap on wd0b dump on wd0b

Re: Is loss of read-only /usr permanent?

[Kevin Chadwick]

> Finally, the read only file systems on a writable medium susceptible
> to all sorts of failure modes is a silly silly useless trick.  This
> does not provide any real technical benefit but your own discomfort.
> 

Pipe it down a bit will you. I use ro root, /dev in tmpfs and /usr ro
as well as any partition where writes do not happen at any time. It is
called defence in depth. Consider a potential bug in tar when run as
root, damaged /usr or / is easily fixed with OpenBSD (one of it's ace
cards) but I have been saved time by ro root before, though I forget the
details and probably just a testing system. When considering doas,
etc., I believe a ro mount to be far simpler than DACs even if they are
well tested. It is also quite reassuring to see clean clean clean clean
after a power failure. Of course a hard drive head could have crashed
onto that area, but very unlikely and I'm not sure fsck would catch
that anyway.

UPS do fail too btw. I had to rip some cheap APC ones out because
they caused more downtime than they saved!

> 
> Except just this time now, when your self managing became a bug report,
> which is not a bug, and you insisted on your way of having it reported.
> 
> Now admit it, you support yourself when you make incompatible changes.

Which is fair enough but has already been said.

-- 

KISSIS - Keep It Simple So It's Securable

Re: doas with a timeout

[Kevin Chadwick]

> sudo was having a nice feature of not overwhelming the user with 
> password prompts (cookies :-) ).
> 
> This diff is adding this back to doas(1).

It's not a big deal but one feature of sudo that I occasionally use is
sudoedit or a one-time su like command with timestamp_timeout=0 to
always prompt for a password for a particular user. So a non root
password could unlock any command as any user once.

Just wondering what peoples thoughts or considerations here are/have
been.

--

KISSIS - Keep It Simple So It's Securable

Re: httpd: hsts (rfc 6797)

[Kevin Chadwick]

On Sat, 18 Jul 2015 02:53:01 +0200
Reyk Floeter wrote:

> HSTS is a good thing and widely pushed, eg. by Google, in an effort to
> enforce HTTPS over HTTP.  It is a useful security option 

I agree HSTS is useful but disagree with the rhetoric personally. It
improves security for average website deployers using bog standard
hosting and large websites that can't control their own sites or
design them properly/well/securely/without js from 10s of domains. For
me, however I don't buy google's argument of it doing "no harm" because
of AES acceleration when SSL amplification DOS is taken into account and
so I hope Google don't push too hard. When my sites get enough demand to
require more than one server then I shall want to *maximise* the
chances of delivering insecure content which dictates http only
servers. Pages can be enforced over SSL without HSTS and cookies too
which many advocates don't seem to realise (that the secure cookie
flags and ways to control them exist).

Re: [Bulk] freetype vulns

[Kevin Chadwick]

On Wed, 04 Mar 2015 17:12:07 -0500
Ted Unangst wrote:

> references this bug:
> http://savannah.nongnu.org/bugs/?43661

Does anyone know how to turn off external font loading in
xombrero's webkit and would doing so avoid a large part of the risk?

Was gonna post to misc@ but judging by this thread so far I wasn't sure
if that may make more noise than desired.

Re: [Bulk] Re: [DIFF] /etc/rc: gracefully shut down base daemons too

[Kevin Chadwick]

On Sat, 21 Feb 2015 11:19:08 +
Stuart Henderson wrote:

> init shuts them down gracefully anyway where possible. When you have
> a misbehaving system, the fewer unnecessary processes to get in the
> way of a reboot, the better.

I've certainly had Linux hang on shutting down services more than once
and never on OpenBSD. I guess less is more, proves itself again.

Systemd may have improved the Linux shutdown with cgroups though I'm
not convinced?? (by doing even more) and it's brought all sorts of
other reliability problems to the table.

Re: Authenticated TLS "contraints" in ntpd(8)

[Kevin Chadwick]

On Tue, 10 Feb 2015 13:03:27 +
David Dahlberg wrote:

> > > The standardized attempts to add authentication to NTP are a) fairly
> > > horrible (ASN.1 etc.) and b) rarely deployed.  
> > 
> > When ntpd acts as a server, could the package signing code be of use
> > with ntpd keys?  
> 
> How exactly? You cannot use signing for PSK, Private Cert GK as they
> require peer-to-peer shared secrets. The rest of the autokey protocols
> do not provide any usable identity checks anyway. Nice read:
> http://zero-entropy.de/autokey_analysis.pdf
> 
> The HTTPS-based scheme is at least able to link a rough time constraint
> to a PKI (which autokey is not even able to do) and it follows the
> general design approach of OpenNTPd: Being simple and good enough for
> most use cases.

I was meaning just for internal OpenBSD use between ntpds really (you
would still need a trusted or checked source with a decent crystal)
without resorting to handing axes out, outside the standards meeting
with the time_t pdf link enscribed in the handle ;-).

Re: Authenticated TLS "contraints" in ntpd(8)

[Kevin Chadwick]

On Tue, 10 Feb 2015 10:55:53 +0100
Reyk Floeter wrote:

> The standardized attempts to add authentication to NTP are a) fairly
> horrible (ASN.1 etc.) and b) rarely deployed.

When ntpd acts as a server, could the package signing code be of use
with ntpd keys?

Re: [Bulk] Re: Shadow TCP stacks

[Kevin Chadwick]

On Sat, 11 Oct 2014 13:38:49 -0400
Ian Grant wrote:

> No, the "pre-shared keys" are communicated over the VPN, as are the
> keys which encrypt the VPN's own data as it appears in the actual TCP
> packets which carry the tunnel through which the VPN operates.

Perhaps I have missed something but if you have a ssh tunnel or
something then just put that in front of the service without increasing
your attack surface.

Re: DNS control port additions to /etc/services

[Kevin Chadwick]

previously on this list Claudio Jeker contributed:

> IMO /etc/services should not be overwritten on upgrade.
> Also if people are careful and only append at the end then merging the
> file with sysmerge should be trivial.

Isn't it trivial to sysmerge in any case? Then again so is adding a line
to rc.local using sed,ed,perl,cat or whatever you prefer to
inject/append your changes?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

Re: IPv6 by default

[Kevin Chadwick]

previously on this list Stuart Henderson contributed:

> My thinking is that *if* someone has taken steps to enable v6,
> then programs should try to use it for comms where possible.
> "family inet6 inet4" is too blunt and affects people who don't want
> to touch v6.

I'm used to seeing NOINET6 in ifconfig and just realised it isn't set
on this machine :-( still it's blocked by PF :-)

If a user says none to ipv6 address in the installer why not set things
appropriately. It occured to me that /etc/rc has PF settings that a
default ipv6 block may prevent initial machine accessibility?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.

(Kevin Chadwick)

___

Re: missing ports.tar.gz in snapshot

[Kevin Chadwick]

previously on this list Shawn K. Quinn contributed:

Makes very little difference to me.

> I don't use the ports tree at all anymore. That said, I would trust the
> empirical evidence (FTP logs) more than any on-list answers you might
> get.

Is there a pkg* tools equivalent to print-run-depends?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

Re: Boot network for remote unlock of fde

[Kevin Chadwick]

previously on this list Kevin Chadwick contributed:

> Though I can understand the FDE approach for Linux due to it's rather
> and pointlessly (IMO) complex boot.

Obviously not all using the linux kernel like buildroot for embedded
which can be literally six lines of shell but probably every
desktop distro.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

Re: Boot network for remote unlock of fde

[Kevin Chadwick]

previously on this list Giancarlo Razzolini contributed:

> I prefer to have /etc and everything else
> encrypted. If not, I would have to move lots of configuration files to
> the encrypted partition, not to mention that it would very error prone.

You can always use symlinks or mount encrypted partitions into
say /etc/ssl.

I believe the absolute OpenBSD original book mentioned you couldn't
have /etc on it's own partition and I guess it must be on root for boot
of /etc/rc but I would also guess you could mount over the top before
starting sensitive data handling services. You would just need to keep
them in sync when upgrading the system and thankfully OpenBSD's startup
is rather neat and can be handled with comparatively little trouble

Though I can understand the FDE approach for Linux due to it's rather
and pointlessly (IMO) complex boot. It seems to me you are going
to a lot of effort to achieve little but a slower system with less
entropy and aiding crypt-analysis a little due to predictable data when
all you really need is a bit of scripting or consideration of how you
can most conveniently and best protect what you need to.

Encrypting logs is no chicken and egg problem and very straight
forward.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

Re: signed packages

[Kevin Chadwick]

previously on this list Giancarlo Razzolini contributed:

I believe that with the interdiction
> programs that NSA has, and maybe also other governments, CD's can not be
> entitled with the same trust as before.

Why would you have so much trust in the ether unless you have met
someone with say a DNSSEC key or have a web of trust with someone you
have met and that you trust and has met and swapped keys further up
the line. The first key for DNSSEC is almost always untrusted, though
you can use SSL to check the fingerprint.

Surely it takes more resources for the NSA to get your particular CD?
and surely you should be prioritising other concerns than the NSA
anyway and would see the CD as a valuable extra authentication?

Along the lines of what the OpenBSD manual says, if the black suits
target you, do you really believe you can stop them?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

Re: signed packages

[Kevin Chadwick]

previously on this list Jiri B contributed:

> What about as TXT record for dns (in combination with DNSSEC) as alternative
> for getting the key? :)

The architecture for the root key handling (offline keys, multiple
people etc.) is good obviously with bobs concerns though.

I don't know much about signify yet except that it looks nicer than the
old system and has been a nice surprise and certainly no nothing of the
plans for it, however you have to verify the first root-anchor anyway
for DNSSEC which can be done by anyone that builds and the anchor is
signed but again requires a web of trust, so there's really no
difference. Except that DNSSECs anchor is bundled with unbound already
and then updates itself if you don't miss the window etc..

DNSSEC does offer some convenience for some things but not here I would
suggest and unless it has moved to ECDSA already?, it isn't secure
anyway with the 768bit RSA limit on TXT record size and also offers DOS
and a potential of a 100x amplification to DDOS.

I certainly have hopes for ECDSA DNSSEC coupled with other things
(DNSCURVE, browser domain control validation) being used to sort out
https with the only thing that counts (simple domain level trust) but
I'm not full of confidence that it will when there is so much money to
be made with the pointless (except PR) EV etc..

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

Re: Request for Funding our Electricity

[Kevin Chadwick]

previously on this list Theo de Raadt contributed:

> > 
> > If the tests are as good as this project claims them to be, the process
> > should take exactly one test cycle. If that's the case, then the test
> > regime suck big time. Logic brother. Logic.  
> 
> the OpenBSD project's purpose is not to test emulators.

And this should be obvious to many that it is a time consuming task to
prove or even have confidence of.

Virtualbox without hardware virtualisation still crashes OpenBSD never
mind being accurate because it's memory handling implementation is so
far removed from x86 atleast.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___

Re: drm bits on 54.html

[Kevin Chadwick]

> >
> > Yes, real world so often uses names and terms improperly. whats new.  
> 
> In real world hacking is cracking :(

That may change, I saw a program on TV recently where Dara O'brien said
hacking is being done on gadgets recently 'not in the traditional
computer science meaning' but in making a gadget do something that it
wasn't intended to do.

Made me laugh and I'm sure you know but I believe the traditional
computer science terms have always been just that.

cracking as beating or finding a weakness in an auth system such as
defeating the encryption or password but using it as intended

hacking as circumventing or beating the auth system not by brute force
etc. but finding a flaw and making it do something it shouldn't like
short circuiting the algorithm.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: goodbye to some isa devices

[Kevin Chadwick]

On Wed, 27 Mar 2013 19:24:49 +
Kevin Chadwick  wrote:

> However, I would be glad if the 486 support was kept as I have many
> 486 systems that I would like to be able to use if I ever get around
> to porting the ethernet driver (which is open source).

Oops, just checked and they are 586 and the older ones are AMDs but I'm
less likely to ever use them.

Re: goodbye to some isa devices

[Kevin Chadwick]

> However, on a practical level, if we took the decision to kill 486 support,
> we could, in effect, loose 99% of the ISA-related code, as excluding a few
> specialised pieces of hardware, (which OpenBSD doesn't support, and probably
> never will), ISA pretty much died by the 586 era, (as did VL-bus).

Whilst I have some p500 systems that I am not using with both pci and
ISA. I certainly have no care for ISA.

However, I would be glad if the 486 support was kept as I have many 486
systems that I would like to be able to use if I ever get around to
porting the ethernet driver (which is open source).

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: Fixing a phrase in /stable.html

[Kevin Chadwick]

> > i asked native english speaker,
> > apparently, taking awhile is always 'sarcastic', and never short.  
> 
> Not according to dictionaries[1][2][4]. I've never thought "awhile" as
> a sarcastic usage.

Well I've never seen awhile written without a space so you can take
this with a pinch of salt but I've heard

"I'm gonna be a while so I'll have to give it a miss" and I've never
heard it rather than something like "I won't be long" even if in
reality that always means they will be ages ;-).

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

On Thu, 22 Nov 2012 15:58:12 -0430
Andres Perera  wrote:

> On Thu, Nov 22, 2012 at 2:53 PM, Kevin Chadwick
>  wrote:
> > On Thu, 22 Nov 2012 14:18:59 -0430
> > Andres Perera wrote:
> >
> >> there's still no tie-in to the privileges of the process,
> >
> > It still lets a process do something unintended. In fact getting a
> > browser to execute an external javascript program is a threat in
> > itself that could have no end of custom instructions executed as a
> > normal user.
> 
> something unintended like fiddling with its registers and increasing
> $pc in gdb
> 

No

> >  In fact getting a browser to execute an external javascript
> > program is a threat in itself that could have no end of custom
> > instructions executed as a normal user.
> 
> i'm convinced that you don't know what javascript is and in spite of
> that decided that it carries along the dom apis wherever it goes, like
> some sort of disfunctional sidekick relationship ala robin and batman
>

Like shell, do you have any idea how much js is capable of.

And yes in my opinion all interpreters should honour noexec and Sudo
does not depend on shell but anyway that was a bonus point to the
unnecessary problem introduced due to lack of collaboration with bodies
of differing backgrounds or almost anyone but Zeuthen in this case.

> >
> >> as explained
> >> in my previous message, and there's also a new, pending tie-in;
> >> "POSIX being influenced by such things" -- i doubt that js is
> >> creeping its merry way into posix.
> >
> > Your twisting my meaning and I'm sure we're just boring everyone and
> > polluting this thread for sure now and this is @tech.
> >
> 
> that's just the pussiest way of saying "i've mistakenly sprayed my
> comments with acronyms like rop and jit, but i have no fucking clue
> how they relate"
> 

I know what I have said and understand it just fine. If you would
like to pick out something specific even though it is besides the main
point then I shall elaborate but please reply on misc@.

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

On Thu, 22 Nov 2012 14:18:59 -0430
Andres Perera wrote:

> there's still no tie-in to the privileges of the process,

It still lets a process do something unintended. In fact getting a
browser to execute an external javascript program is a threat in itself
that could have no end of custom instructions executed as a normal user.

> as explained
> in my previous message, and there's also a new, pending tie-in; "POSIX
> being influenced by such things" -- i doubt that js is creeping its
> merry way into posix.

Your twisting my meaning and I'm sure we're just boring everyone and
polluting this thread for sure now and this is @tech.

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

On Thu, 22 Nov 2012 13:27:46 -0430
Andres Perera wrote:

> but jit isn't irreparably interleaved with js
> 

The latest polkit actually depends on the javascript package.

> am i compromising by running luajit in interpreter mode instead of the
> reference implementation, moreover, would that imply that lua the
> language is insecure or is the specific implementation at fault?
> 
> why would the runtime be attractive for rop?

having the javscript package on your system when you otherwise
wouldn't can allow an attacker to use code he is likely familiar with
return to libc style to modify the capability of code marked executable.
This may not generally mean that much but on a small server or embedded
system it may mean a lot. The main point is that this is an example of a
Redhat developer having free reign to do silly things and actually
increased the difficulty of the average human configuring polkit and
without evaluating all potential consequences and scenarios. POSIX being
influenced by such things is wrong.


p.s. When I said polkit is cross-platform, I really meant it's
portable.

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

On Thu, 22 Nov 2012 09:30:41 -0430
Andres Perera wrote:

> i'm not sure how using js for configuration files, as opposed to using
> a language commonly deployed for the same purpose, such as lua,
> presents an innate constraint on security.

Firstly the article mentioned JIT preventing true randomisation.

Secondly pulling in JS as a dependency even on servers is rediculous and
is a language very familiar to attackers and unfamiliar to many users.
It would be especially, shall we say kind to attackers utilising rop
attacks.


> 
> then i would point out that, if anything, a popular js implementation
> receives broader testing than sudo's dsl.

And it needs it and turns up bugs every week and grows constantly. Are
you serious!

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

> Follow-up interview, much better to say what you want instead of having people
> interpret your email.

Do you know polkit (which I believe is cross platform but I prefer to
remove it, primarily because it gives little indication of what is
allowed and requires constant review, unlike sudo) now uses Javascript
for it's configuration files because the author (from his blog)
believed JS to be the most universal language he could think of. I'm
still unsure if he's serious or just taking the piss. I'm sure though
he writes security software, he didn't realise any security
ramifications in any case.

Anyway sorry to lower the tone. Cross polination and health is
important. Less can certainly be more and mean more sooner for everyone.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

On Thu, 8 Nov 2012 10:18:28 +0100
Lars von den Driesch wrote:

> >> > The only distros with a fair few users who have switched and still
> >> > have far less users are Fedora, Mageia and OpenSUSE.  
> >>
> >> Let's have an eye on Arch-Linux.  
> >
> > And they have lost users over it. I left them out because they have few
> > users in comparison. What do you mean by having an eye? To me, Arch has
> > absolutely zero bearing on what I have said?  
> 
> Well, then probably I didn't get what you wanted to say.
>

The main point was that systemd advocates constantly re-iterate FUD
that systemd is inevitable and you are/will be in the minority if you
don't switch. I'm complicatedly pointing out that actually systemd
systems will be in the vast minority for the foreseeable future.

> I just know I am reading this list because Arch switched to systemd
> and I am looking for alternatives.

Good Luck. OpenBSD is brill, but there is a learning curve (updating
etc..) and less devs than ideal but less devs has it's quality merits
too (has many more devs than arch though). Sabayon Server may make a
good start as a replacement for Arch also?

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

On Wed, 7 Nov 2012 22:52:19 +0100
Lars von den Driesch  wrote:

> > The only distros with a fair few users who have switched and still
> > have far less users are Fedora, Mageia and OpenSUSE.  
> 
> Let's have an eye on Arch-Linux.

And they have lost users over it. I left them out because they have few
users in comparison. What do you mean by having an eye? To me, Arch has
absolutely zero bearing on what I have said?

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

> and if you come with proper arguments (and code) they will be more than
> happy to include it or change the way they do things to accomodate to
> standards. Lennart is a different matter, he made it clear he doesn't
> care about the rest of the ecosystem. But he is just one guy and his
> lobbying works also because no one else is here to challenge him. It's
> one thing to rant on mailing list and blobs...

I know Lennart comes out with some right rubbish and utterly
pointless and misleading hype from this link but whether he is pulling
strings I do not know and in any case does not change the facts.

http://0pointer.de/blog/projects/security.html

It's stated time and again that if you are a Linux distro you will have
to switch to systemd sooner or later. It was even said on this list
debian will switch without giving evidence, was it the hype?. I welcome
any recent links to contradict me? You get a similar thing in football,
if some say someones the best defender enough times, even if they are
judging him on his shooting ability then many believe it. Something
that's cost England dearly.

The limited decision process I saw from the debian leader said let's
wait ten years and consider openrc in the meantime and it wasn't just
because debian has BSD interests.

http://lwn.net/Articles/512719/

Aside from systemd being slated technically on the Gentoo and also the
Sabayon lists
(http://lists.sabayon.org/pipermail/devel/2012-August/008278.html)

Gentoo have said something like, we are about freedom and as systemd is
curtailing that we are more likely to drop Gnome than support a default
of systemd. Of course as choice is our main goal we hope systemd will
run too, it will just be unsupported.

As I have said I don't think anyone knows the figure but if Gnome
becomes dependent on systemd, they are isolating most of their
potential user base provided by Debian, Ubuntu and Gentoo and it's
livecd derivitives and sending half their users over to the likes of
KDE/XFCE that have already gnudged ahead.

The only distros with a fair few users who have switched and still
have far less users are Fedora, Mageia and OpenSUSE.


So there are many many annoyed by this and it should hit true,
especially as KDE has apparently already overtaken Gnome as the most
used desktop. I just hope you get your answer sooner but from Gnomes
recent record, I'd be worried too, so Good luck and keep us informed
please.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

On Tue, 6 Nov 2012 21:39:42 +0100
Marc Espie  wrote:

> I don't have ANY KIND OF SOLUTION.

Certainly couldn't for that general problem without likely being the
problem.

As I've said before I'm not a Gnome fan and far from a Gnome 3 fan
however the reason udisks dropped many gnome features like automount
for over 6 months was due to RedHats drive for multiseat which actually
99% of Linux care nothing about and perhaps has something to do with
all the feature bloat and dependency issues in order to get the
support from the community. Lennart has said (in a slghtly reasonable
manner for once) in the thread Antoine was involved in on Gnomes list
that multiseat is a large part of the portability issue.

As Gnome already has dilemmas affecting user experience possibly
wanting splits into.

Touchscreen mode

Touchscreen and mouse mode

mouse mode

Perhaps an Enterprise multiseat mode as well as these would atleast in
my opinion and pointed out in this heise article perhaps save their
bacon as the main linux desktop.

http://www.h-online.com/open/features/GNOME-from-abyss-to-common-ground-1667974.html

I can't see OpenBSD caring one bit about losing out on "Enterprise
mode" ;-)

Re: upstream vendors and why they can be really harmful

[Kevin Chadwick]

Apparently branding as a priority by some devs, is a major reason. I
can't believe a Gnome dev said he hadn't heard of XFCE to a
transmission dev!

http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/

> in some cases, you even have some people, who are PAID by some vendors,
> agressively pushing GRATUITOUS, non compatible changes. I won't say names,
> but you guys can fill the blanks in.
> 
> I'm pretty sure there's a lot of good intention behind the "progress" in
> recent desktops. But this is turning the field of OS distributions into
> a wasteland. Either you're a modern linux with pulseaudio and pam and
> systemd, or you're dying.  So much for the pionneer spirit of opensource,
> where you were free to innovate and do cool things, and more or less have
> interesting software able to run on your machine...

It could well end up the other way around, with systemd dying. It does
far too much and most of which is pointless in order to gain traction
but also limiting it's scope and so success unless it is forked or
radically changed of course. The amount of code running as root is
rediculous too. Even Redhat devs have said it offers little and it
certainly causes major problems even for Linux.

The Linux communities are still keeping some freedom (Gentoo, Debian).
It's said Debian is just because of HURD but I don't think that's true,
though the argument would be long.

Rather than spending time on these, are trinity and mate etc.. worth
looking at?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: Scheduler improvements

[Kevin Chadwick]

> It appears to have sped up porn. movies on the machine seem a bit better.
> 
> I will try this in a few other places

Just not at the mother in laws or in public places no matter how
impressed you are at the difference?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: tcp ping

[Kevin Chadwick]

> I haven't polished the output
> because I'm not sure if this is desirable or not, but I found it
> useful.

I'd like it, it's always made sense to me to test a service using the
protocol it uses and would remove a package install.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: Future of PF

[Kevin Chadwick]

On Sat, 19 May 2012 21:09:03 -0400
Jiri B wrote:

> You can suggest whatevery you want, words are for free :

:D

Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]

[Kevin Chadwick]

On Mon, 05 Dec 2011 10:53:00 +0100
"Sebastian Reitenbach" wrote:

> So to be able to shoot myself in the foot without the need to compile the 
> kernel, I'll look into adding a sysctl to tweak the maximum size of the 
> buffer. Well, depending on time and how fast I figure out how to do that, 
> might take some time.


I don't know the best word but what about something like
net.inet.tcp.footshooter.

You'd have to be pretty dumb. To write into the mailing list saying

I don't know what's wrong. The only changes I've made are to increasse
performance by tweaking net.inet.tcp.footshooter.sbmax?

Re: Design of spamd

[Kevin Chadwick]

On Wed, 30 Nov 2011 20:00:27 +0100
Han Boetes wrote:

> So for some reason passtime is ignored on my machine. I've tested
> this with telnet quite extensively. And after 3,4,5 attempts in a
> minute or so the address is whitelisted.

What version of OpenBSD are you running? Does it do this without your
addon scripts?

Re: Design of spamd

[Kevin Chadwick]

On Mon, 28 Nov 2011 23:08:52 +0059
Han Boetes wrote:

> So spamd would use the stuttering time to figure out if the ip is
> not on an rbl, if the dnsname is reverse resolvable, if the helo
> is valid, if the sender is not matching silly pattern, etc etc and
> then decide what to do with the attempt, either blacklist or
> whitelist the ip. Wouldn't it be nice if spamdb could feed it's
> data to a rbldnsd so other mailservers in the domain could use the
> same information?
> 
> I think it would result in a much faster and fairer decision
> building if a message is spam or ham.

Have you looked at greyscanner in ports. The beauty of spamd is it's
configurability. It's easy to add dnsbl support to it with a simple
script (for older email addresses you can't be proactive with). That
being said I'm sure there's a fair few doing this. Maybe it's so easy
no-one thought it was worth doing a greydnsblscanner to put in ports?

I'll send mine if you like and then everyone can laugh at how
quickly and crudely I wrote my script ;-).

Re: enable aucat by default

[Kevin Chadwick]

On Fri, 07 Oct 2011 12:31:16 -0600
Theo de Raadt wrote:

> And precisely how do you do that?

I was thinking turn on if X is enabled during the installer and throw
inputless warning that you should turn it on manually for servers or
consoles that desire it if X is declined.

Re: enable aucat by default

[Kevin Chadwick]

On Fri, 07 Oct 2011 10:35:27 -0600
Theo de Raadt wrote:

> The plan is to gut the direct device code-paths substantially, and
> stop trying to perform magic two ways.  The direct-device methods will
> continue to work, but only as minimally as they did 10 years ago.

Even better, a simpler audio system and less code in memory. I'd rather
enable it manually as I rarely turn my speakers on anyway and don't
want this leading to an easy ride for other code to be loaded as I
think henning was getting at but wasn't going to type in names manually.

I have no problem enabling it for systems that need audio as I will have
to do configuration anyway.

What about, turn on for X and have to manually enable otherwise.

Re: relayd session timeout

[Kevin Chadwick]

On Thu, 1 Sep 2011 10:21:35 +0200
Alexander Bluhm  wrote:

> The relayd used the CHECK_TIMEOUT for connect and ssl handshake.
> This is 200 milliseconds and too short.  Instead use the 600 seconds
> session timeout that is used for accepted sessions everywhere else.
> 
> While there, make flag handling in relay_ssl_transaction() consistent
> to the other functions.

That may explain why I had to edit my config for Opera which
doesn't use a new connection on certificate acceptance etc..

Re: Small pgrep/pkill enhancement

[Kevin Chadwick]

On Sun, 12 Jun 2011 16:31:32 +
Kevin Chadwick wrote:

> On Sun, 12 Jun 2011 00:15:58 +0200
> Benny Lofgren wrote:
> 
> > Me personally, I'm scared as hell using pkill at all. I've never been
> > concerned with not killing *enough*, it's almost always that I'm afraid
> > I'm killing too *much*...
> 
> Most of the time, the regex matching makes it usable. I'd rather see
> that expanded than case sensitivity.
> 

Of course you can use ps -auxww | egrep | cut etc. etc. when needed,
instead of pgrep but that sort of defies the point of pgrep.

Re: Small pgrep/pkill enhancement

[Kevin Chadwick]

On Sun, 12 Jun 2011 10:41:16 -0500
Chris Bennett wrote:

> I would like a verbose option where I can be notified if nothing matched.

/usr/bin/pgrep asxbabsjkcnjklcneo || /bin/echo "Nout matched"

Re: Small pgrep/pkill enhancement

[Kevin Chadwick]

On Sun, 12 Jun 2011 00:15:58 +0200
Benny Lofgren wrote:

> Me personally, I'm scared as hell using pkill at all. I've never been
> concerned with not killing *enough*, it's almost always that I'm afraid
> I'm killing too *much*...

Most of the time, the regex matching makes it usable. I'd rather see
that expanded than case sensitivity.

Re: En/disabling power button shutdown

[Kevin Chadwick]

On Sat, 11 Jun 2011 21:14:02 +0200
gilbert.fernan...@orange.fr wrote:

> They had to put pieces of paper in front of the power buttons
> because when you move a machine sometimes your finger presses
> the power button.

A matchbox with a hole in it acts like a reset button protection.

Re: Filesystem Hierarchy Standard (FHS) and OpenBSD

[Kevin Chadwick]

On Tue, 10 May 2011 09:05:13 +0200
Landry Breuil wrote:

> Some parts of FHS won't apply on OpenBSD, like /srv, /opt,

Linux ignores security mechanisms like noexec on /tmp, /home and then
pointlessly adds /opt seemingly just to annoy people who care about
partitioning!!

And DON'T try spinning me the line that noexec is pointless on /tmp.

I'm glad of your Open thought process though. :-)

Re: horribly slow fsck_ffs pass1 performance

[Kevin Chadwick]

On Sat, 02 Apr 2011 17:46:51 +0200
Benny Lofgren wrote:

>  It must mean they don't trust their own file
> systems, which frankly I find a bit unsettling... I'd rather use a file
> system that's been field proven for decades than use something thats
> just come out of the experimenting shop.

Hopefully they're just trying to highlight that windows seems to skip
checks 70% of the time after unsafe shutdowns.

Re: top, systat and hw.cpuspeed

[Kevin Chadwick]

On Thu, 24 Mar 2011 13:23:08 +0100 (CET)
David Vasek wrote:

> I am fully aware that it is not always completly exact, and but on the 
> other hand the CPU clock rate doesn't change immediately, it takes at least
> 5 seconds to drop/rise after the CPU load changes. At least on my Pentium-M 
> based Thinkpad, where I run apmd -C. 
I've seen an intel tool just for this job showing the cpu scaled up for
a second at a time.

>Much better displaying this than nothing, I believe.

Sustained is certainly more important to a process monitor normal usage,
when batteries don't matter.

Re: Allegations regarding OpenBSD's PRNG

[Kevin Chadwick]

On Wed, 22 Dec 2010 11:00:43 -0600
Marsh Ray  wrote:

> But a typical box doesn't have "hundreds and hundreds" of processes or 
> unpredictable event sources. There are 300 or so references in the 
> source tree, but most of them are in code that doesn't run on any given 
> machine.
> 
> A special-purpose box (e.g. a IPsec VPN gateway) may have very few other 
> than network events, which are known to an outside observer to a 
> significant degree.

Well I would have thought it's certainly better, though I'm not in the
crypto internals know and haven't been studying very closely, so I can't
comment.

Cron, Mail server, web server, relays all create many processes and you
should be monitoring any important system too.

The unix philosophy of many small programs means a high number of
processes is rather likely. The daily script itself uses many, though
admittedly in this case only once a day.

Isn't the stream used for random pids e.g. all processes?

Re: Allegations regarding OpenBSD's PRNG

[Kevin Chadwick]

On Wed, 22 Dec 2010 05:08:56 -0600
Marsh Ray  wrote:

> Let's say I could sample the output of the RNG in every process and from 
> every network device in the system. As much as I wanted. How could I 
> tell the difference between "one prng per purpose" and "data-slicing one 
> prng with all consumers"?

There was a thread "called how to use /dev/srandom" where theo sent
this, which may be relevant?

===

For those who don't want to go read the code, the algorith on the very
back end is roughly this:

(a) collect entropy until there is a big enough buffer
(b) fold it into the srandom buffer, eventually

That is just like the past.

But the front end is different.  From the kernel side:

(1) grab a srandom buffer and start a arc4 stream cipher on it
   (discarding the first bit, of course)
(2) now the kernel starts taking data from this on every packet
   it sends, to modulate this, to modulate that, who knows.
(3) lots of other subsystems get small chunks of random from the
   stream; deeply unpredictable when
(4) on very interrupt, based on quality, the kernel injects
something into (a)
(5) re-seed the buffer as stated in (1) when needed

Simultaneously, userland programs need random data:

(i) libc does a sysctl to get a chunk from the rc4 buffer
(ii) starts a arc4 buffer of it's own, in that program
(iii) feeds data to the program, and re-seeds the buffer when needed
 
The arc4 stream ciphers get new entropy when they need. But the really
neat architecture here is that a single stream cipher is *unpredictably*
having entropy taken out of it, by hundreds of consumers.  In regular
unix operating systems, there are only a few entropy consumers.  In
OpenBSD there are hundreds and hundreds.  The entire system is full
of random number readers, at every level.  That is why this works
so well.

Re: Solvng the NVIDIA IDE/SATA/AHCI mess

[Kevin Chadwick]

On Tue, 21 Dec 2010 11:27:30 +0100 (CET)
Mark Kettenis  wrote:

> We still have some some issues with SATA/AHCI on NVIDIA chipsets.  If
> you have a machine, could you send me the following information:
> 
> * dmesg
> * output of 'pcidump -vxx'
> * BIOS setting (IDE/SATA/AHCI/RAID) if your BIOS provides that opportunity
> * short description of any changes (BIOS settings, kernel config) you
>   need to make to get things working.
> 
> If your machine has the possibility to change the mode of the disk
> controller in the BIOS, and you're willing to spend some time, please
> try them all and and send me a report for all of these.  Note that
> this may cause your disk to change from wd* to sd* or the other way
> around.  So you may need to (temporarily) change your /etc/fstab.
> 
> Thanks,
> 
> Mark
> 

I have an old athlon 64 nvidia board that used to work with 3.8 but
last time I tried it (I think 4.6), it wouldn't boot (kernel restart)
without disabling usb in the bios. I use OpenBSD on i386 so it's no
issue to me but I've no problem running some info gathering etc. but
are you wanting to concentrate on the newer boards, possibly being less
troublesome and more useful to get working for hardware released in the
future?

Re: Allegations regarding OpenBSD IPSEC

[Kevin Chadwick]

Does anyone know if there was an ultimate outcome to the investigation
of side channels supposedly put into DSA by the NSA?

Re: Allegations regarding OpenBSD IPSEC

[Kevin Chadwick]

On Wed, 15 Dec 2010 14:57:24 -0700
Tobias Weingartner  wrote:

>  So in this case, you're the one that is out of
> line.

If your talking to me then I tried to make it clear that I was sitting
on the fence. I was going to go further but then figured that would be
leaning in one direction. I certainly wouldn't want to offend anyone I
don't know but I'm not going to defend them or help their case if I
don't know whether they're guilty or not either.

If your putting evidence forward, then logic dictates that the same
reasoning applies in that it doesn't clear you unquestionably unless it
proves something which is why I asked if it did. Don't get me started
about law, because it's more about money than justice and please don't
read between my lines.

For what it's worth, my opinion which is irrelevant on the basis of next
to no evidence was that Jason is likely the one telling the truth and
I'm sure the people in the community that count to him will have a
better idea than me.

My intention was not to drag anyone through the mud but only help people
get to the truth, sorry if it also seemed like that to anyone else. If
he's wrongly accused for financial gain then that is truly terrible.

Re: Allegations regarding OpenBSD IPSEC

[Kevin Chadwick]

On Wed, 15 Dec 2010 10:27:31 -0800
"Jason L. Wright"  wrote:

> I
> cannot fathom his motivation for writing such falsehood (delusions
> of grandeur or a self-promotion attempt perhaps?)

Perhaps,

Promote his domains rank in google or the facebook link? (Does anyone
know if he always puts facebook links in mails)

Wants IPSEC audited for some reason?

Divert devs attention from something else?

If it's one of these reasons or any other alterior motive then that's
just dispicible.

However, NDAs often last for 10 years which either adds weight to
the well thought urban myth theory or to the possibility that it may be
the truth.

>The real work on OCF did not begin in earnest until February 2000.

I can't see how this gives you credibility but maybe the people who
worked with you at the time can understand how your evidence supports
what you say.

Re: bugfixes for dc(4)

[Kevin Chadwick]

On Tue, 14 Dec 2010 04:16:46 -0500 (EST)
logana...@devio.us (Loganaden Velvindron) wrote:

> Hi,
> It fixes the idle timeout messages (which is not an issue on PNIC) and sets 
> the speed to 10BaseTX, since autonegociation is broken on PNIC.
> 
> //Logan
> C-x-C-c
> 

I had a dc with timeout messages during boot and trouble getting it to
then work. I think?? I had to fix it with a hostname.dc0 config and it
worked for over a year, but after a reinstall, I had lost track of what
I had done previously to fix it and so just swapped the nic. dc seems
to get some praise in the man page too.

Re: update pms driver

[Kevin Chadwick]

On Mon, 29 Nov 2010 22:08:22 +
Nicholas Marriott  wrote:

> Well, I don't use it so I don't have strong feelings about it, but it
> does work for PS/2 mice and it seems that it would be useful for anyone
> using wsmoused (although there probably aren't many people).

I use xset m, that isn't affected is it? and so is an alternative,
though maybe it could affect someones current setups?

Re: acpithinkpad(4) fan control

[Kevin Chadwick]

On Mon, 22 Nov 2010 16:01:18 -0600
joshua stein  wrote:

> it would be helpful to have some kind of
> watchdog to reset the fan to auto/high if something goes wrong, but
> i don't know whether that's even possible.  while probably not a big
> issue on a laptop, if the fan was on manual/low when the kernel
> panicked and left to sit there for many hours, some things could
> overheat.

Almost all modern processors cut the current back and often switch the
system off regardless of any bios/acpi settings.

This may cause a bit off stress on components around heat syncs etc,
but generally the only problems caused are to data on hard disks due to
unexpected shutdowns.

The only real thing to worry about, would be it shutting off more
often than it should or when you want to run traces after the panic
etc..

Re: more usb detach love

[Kevin Chadwick]

On Wed, 24 Nov 2010 20:59:22 +
Jacob Meuser  wrote:

> thoughts?

Probably not the thoughts your after especially on tech, but some of the
panics I was seeing a while back (keep meaning to run more recent and
proper tests with output, but time is short at the mo) would occur just
after device removal and only with certain usb readers. If I remember
right, usually after bb_reset messages. This along with other work on
usb I've seen definately seems to ring bells.

I'll try to find the time to see if my 4.8 snapshot can be paniced with
some troublesome readers, though I'm not sure if the ones that were
troublesome varied on 4.5/4.6? and 4.7. Anyway, If I can, I'll try
your patch

Re: sync adduser with installer

[Kevin Chadwick]

On Fri, 29 Oct 2010 15:02:05 +0200
Tobias Ulmer  wrote:

> "useradd really does that?  A new group for every user?  I think that
> is stupid behaviour."
> 
> So, I stand by my patch,
> Tobias

Personally I prefer the unique group by default behaviour, but I also
don't have a problem with double checking that my scripts are explicit,
as they should be anyway, however if someone has setup the users group
or wants to use it for something in particular then they are more
likely to specify the group and OpenBSD usually leaves things disabled
by default.

Re: usb xfer timeout issue

[Kevin Chadwick]

On Sun, 17 Oct 2010 23:01:01 +
Jacob Meuser  wrote:

> unless someone sees a problem, or has a better solution, I think this
> should go in soon.

Xfer and bb_reset rings bells with some panics I had. If/when this goes
in and I find time I'll try all the devices I've had problems with
(different devices, different releases, I think, weird, certain usbs
always fine) and see if I can get a panic/lock-up.

Many Thanks for all the usb work

Re: important new unit

[Kevin Chadwick]

> On Wed, 13 Oct 2010 20:02:47 -0400 (EDT)
> Ted Unangst  wrote:
> 
> > Let's say you have a football field in need of a trimming, but the lawn 
> > mowers are all broken, but you have an oxen store nearby.  Oh, and the big 
> > match is in an hour.  How many oxen do you need?
> > 
> > Normally, you'd use units, but...
> > You have: m2/hr
> > You want: ox
> > unknown unit 'ox'
> > 
> > Easy fix.  Working from historical defintion of an acre as the area an ox 
> > can work in a day, we get:
> > 
> > You have: m2/hr
> > You want: ox
> > * 0.0059305292
> > / 168.61902
> > 
> > Tada!  Now you know that 6400 m^2 field you have is going to require 38 
> > oxen.
> > 
> > Index: units.lib
> > ===
> > RCS file: /home/tedu/cvs/src/usr.bin/units/units.lib,v
> > retrieving revision 1.11
> > diff -u -r1.11 units.lib
> > --- units.lib   17 Jul 2002 16:42:12 -  1.11
> > +++ units.lib   13 Oct 2010 23:49:55 -
> > @@ -180,6 +180,8 @@
> >  
> >  acre   4840 yd2
> >  
> > +ox acre/day
> > +
> >  cc cm3
> >  liter  kilocc
> >  ml milliliter
> 
On Thu, 14 Oct 2010 09:19:31 +0100
Kevin Chadwick  wrote:

> Just what i was looking for, but how many shovels will I need for the
> shit?
> 
> 
> If I get 6400 oxen, maybe they'll have to tread it in.
> 
> 

Arrgh, I couldn't get the last 100 of the field in time and with my
antics they started shitting everywhere.


I guess, the moral of the story, Don't cheat or you'll end up covered in
shit at some point. 

XMicrosoftX IBM should have read this in '83 ;-)

Re: important new unit

[Kevin Chadwick]

Just what i was looking for, but how many shovels will I need for the
shit?


If I get 6400 oxen, maybe they'll have to tread it in.


On Wed, 13 Oct 2010 20:02:47 -0400 (EDT)
Ted Unangst  wrote:

> Let's say you have a football field in need of a trimming, but the lawn 
> mowers are all broken, but you have an oxen store nearby.  Oh, and the big 
> match is in an hour.  How many oxen do you need?
> 
> Normally, you'd use units, but...
> You have: m2/hr
> You want: ox
> unknown unit 'ox'
> 
> Easy fix.  Working from historical defintion of an acre as the area an ox 
> can work in a day, we get:
> 
> You have: m2/hr
> You want: ox
> * 0.0059305292
> / 168.61902
> 
> Tada!  Now you know that 6400 m^2 field you have is going to require 38 
> oxen.
> 
> Index: units.lib
> ===
> RCS file: /home/tedu/cvs/src/usr.bin/units/units.lib,v
> retrieving revision 1.11
> diff -u -r1.11 units.lib
> --- units.lib 17 Jul 2002 16:42:12 -  1.11
> +++ units.lib 13 Oct 2010 23:49:55 -
> @@ -180,6 +180,8 @@
>  
>  acre 4840 yd2
>  
> +ox   acre/day
> +
>  cc   cm3
>  literkilocc
>  ml   milliliter

Re: Kill suser() call in tunopen()?

[Kevin Chadwick]

On Wed, 22 Sep 2010 15:37:50 +0100
Owain Ainsworth  wrote:

> On Wed, Sep 22, 2010 at 11:45:10AM +0100, Kevin Chadwick wrote:
> > On Wed, 22 Sep 2010 11:25:02 +0100
> > Owain Ainsworth  wrote:
> > 
> > > On Tue, Sep 21, 2010 at 06:32:50PM -0700, Matthew Dempsky wrote:
> > > > /dev/tun* are already owned by root and mode 0600 by default, so it
> > > > seems redundant to check suser() in tunopen().
> > > 
> > > Looks like vnd could have the same change for the same resons.
> > > 
> > > If so i'll whip up the requisite two-liner.
> > > 
> > > -0-
> > > -- 
> > > Computers are useless.  They can only give you answers.
> > >   -- Pablo Picasso
> > > 
> > 
> > I can see potential reasons for changing the user on tun devices and
> > so saw no problem at all. I wonder if it is better however to have the
> > check at runtime for things like vnconfig, could having the wrong user
> > jeopardise an encryption password at all?.
> 
> Reading the code, you can do VNDIOCGET, that gets you the filename,
> device and inode of the vnd, that is it. The other ioctls are the
> standard disk ones, create vnd (takes a key) and delete vnd.
> 
> We have device permissions for a reason, i find it questionable to
> redundantly check, if you change permisions to let any man or his dog
> create a vnd, you deserve what you get.
> 
> -0-
> -- 
> Graduate life: It's not just a job.  It's an indenture.
> 

Thanks for checking and I realised that in most cases you'd need to be
root or some planned user and so could probably? read that memory
anyway.

I just imagined it was put there for a reason and don't see what harm it
could do and potentially that it could do good, but I see my
reasoning was wrong and I should have took time and thought a bit
harder before responding. Could it be to prevent an admin from setting
up a restricted user that is just able to use that device because that
user would gain access to some sensitive memory and so the admin should
setup sudo instead?

Anyway just thought I'd run a possible reason for it being there past
you. Sorry if we find I'm just wasting your time.

Kc

Re: Kill suser() call in tunopen()?

[Kevin Chadwick]

On Wed, 22 Sep 2010 11:25:02 +0100
Owain Ainsworth  wrote:

> On Tue, Sep 21, 2010 at 06:32:50PM -0700, Matthew Dempsky wrote:
> > /dev/tun* are already owned by root and mode 0600 by default, so it
> > seems redundant to check suser() in tunopen().
> 
> Looks like vnd could have the same change for the same resons.
> 
> If so i'll whip up the requisite two-liner.
> 
> -0-
> -- 
> Computers are useless.  They can only give you answers.
>   -- Pablo Picasso
> 

I can see potential reasons for changing the user on tun devices and
so saw no problem at all. I wonder if it is better however to have the
check at runtime for things like vnconfig, could having the wrong user
jeopardise an encryption password at all?.

Re: add rc.firsttime to rc(8)

[Kevin Chadwick]

> Also may I stand up in support of banana-shaped bikesheds.
> 
How about a sphere, that way you can't be blamed for it being messy