bought an Audigy soundcard hoping it'd work.

2021-08-17 Thread Luke Small
I have a cheap 6450 radeon graphics card with unsupported audio and an
Audigy FX

I hoped Audigy card would work on the emu(4) driver, but doesn't seem to.

I turned on sysctl kern.audio.record=1

Any thoughts?

dmesg:
...
azalia0 at pci3 dev 0 function 1 "ATI Radeon HD 6400 Audio" rev 0x00: msi
azalia0: no supported codecs
...
azalia1 at pci13 dev 0 function 0 vendor "Creative Labs", unknown product
0x0012 rev 0x01: msi
azalia1: codecs: Realtek/0x0899
audio0 at azalia1
-Luke
-- 
-Luke


Can lmdb library linked C code be profiled?

2021-06-10 Thread Luke Small
I’ve discovered that C source code only seems to be able to be profiled by
gprof profiled with gcc (or egcc from gcc package) and with the “-static”
flag to static link the program. But statically linked code which uses lmdb
with lmdb.a from the lmdb package will throw compile-time errors. Is there
a way?--
-Luke


Re: I can’t get veb/vport to work with vmd.

2021-05-06 Thread Luke Small
I got it working. I have a pretty hefty amount of vether0 and
vether0:network in my pf.conf that I changed to vport0 and vport0:network.

That fixed every single thing!

I somehow completely forgot about all the vether0 pf rules which isolates
the the various local systems so VMs are isolated from being able to do
anything malicious to any local systems.

I silently redirect the VMs' dns and ntp calls to my OpenBSD services to
harden them a bit too.

-Luke


I can’t get veb/vport to work with vmd.

2021-05-05 Thread Luke Small
There seems to be ZERO examples of using veb/vport vs bridge/vether. I am
running 6.9 now and I substituted the bridge0 usage in vm.conf and I copied
the hostname.vether0 into hostname.vport0 and hostname.bridge0 uses vether0
so I used vport0 in hostname.veb0 . I used ifconfig … down for bridge0 and
vether0 and ifconfig … up for vport0 and veb0 and ran “sh /etc/netstart
veb0 then ran the vm of choice and it gets no internet. I reverted
everything back and I get internet.

What am I missing?
-- 
-Luke


Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-05-02 Thread Luke Small
I didn’t think of that one. I’ll try to remember that in the future.

On Sun, May 2, 2021 at 4:19 PM jpeg bild  wrote:

> I mean use the usb stick for the files mormozoid. boot using bsd.rd and
> at the "upgrade" prompt instead of selecting http mount your drive and
> select "disk" and type in the location of the mount
> On Sun May 2, 2021 at 12:34 PM CST, Luke Small wrote:
> > There has to be a valid partition to install it to. When I have an
> > encrypted drive, that doesn’t exist using usb…chudazoid.
> >
> > On Sun, May 2, 2021 at 1:31 PM jpeg bild  wrote:
> >
> > > No you don't chudazoid, you just select your usb disk with the file
> sets
> > > after selecting "disk" as your file location
> > >
> > > On Sat May 1, 2021 at 7:37 PM CST, Luke Small wrote:
> > > > I would do that, but I’ll have to figure out how to manually mount my
> > > > encrypted partition, which sysupgrade and bsd.rd takes care if for me
> > > > automatically.
> > > >
> > > > On Sat, May 1, 2021 at 8:07 PM jpeg bild 
> wrote:
> > > >
> > > > > Use the fastly mirror, or download the files to a usb stick and
> select
> > > > > "disk" at the prompt. once you go current you can't go back, and
> its
> > > > > very clearly said in the FAQ as ashton said
> > > > >
> > > > > On Sat May 1, 2021 at 6:25 PM CST, Luke Small wrote:
> > > > > > I tried that by the way. I even mv’ed my pf.conf to nullify it
> and
> > > > > > tried
> > > > > > and it couldn’t download from the gigenet mirror which
> absolutely has
> > > > > > the
> > > > > > 6.9 files. It didn’t work at all. Sysupgrade really needs to be
> able
> > > > > > to be
> > > > > > working on versions as well as -r and -s! The program isn’t
> > > > > > intelligent
> > > > > > enough.
> > > > > >
> > > > > > On Sat, May 1, 2021 at 5:26 PM jpeg bild 
> > > wrote:
> > > > > >
> > > > > > > If you want to move back to stable, you would have to boot
> bsd.rd
> > > and
> > > > > > > select "Upgrade" in the prompt, then install from http with the
> > > correct
> > > > > > > path for 6.9-stable
> > > > > > >
> > > > > > > On Fri Apr 30, 2021 at 9:49 PM CST, Luke Small wrote:
> > > > > > > > We’re there major irreversible changes made to the following
> > > > > snapshot:
> > > > > > > >
> > > > > > > > kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr
> 26
> > > > > 02:26:53
> > > > > > > > MDT
> > > > > > > > 2021
> > > > > > > >
> > > > > > > > which would render in incapable of a downgrade?
> > > > > > > > --
> > > > > > > > -Luke
> > > > > > >
> > > > > > > --
> > > > > > -Luke
> > > > >
> > > > > --
> > > > -Luke
> > >
> > > --
> > -Luke
>
> --
-Luke


Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-05-02 Thread Luke Small
That change to undo the “supersede” command to look at the local unbound
server in dhclient.conf fixed it.

Downloading 6.9 release as we speak.

On Sun, May 2, 2021 at 1:34 PM Luke Small  wrote:

> There has to be a valid partition to install it to. When I have an
> encrypted drive, that doesn’t exist using usb…chudazoid.
>
> On Sun, May 2, 2021 at 1:31 PM jpeg bild  wrote:
>
>> No you don't chudazoid, you just select your usb disk with the file sets
>> after selecting "disk" as your file location
>>
>> On Sat May 1, 2021 at 7:37 PM CST, Luke Small wrote:
>> > I would do that, but I’ll have to figure out how to manually mount my
>> > encrypted partition, which sysupgrade and bsd.rd takes care if for me
>> > automatically.
>> >
>> > On Sat, May 1, 2021 at 8:07 PM jpeg bild  wrote:
>> >
>> > > Use the fastly mirror, or download the files to a usb stick and select
>> > > "disk" at the prompt. once you go current you can't go back, and its
>> > > very clearly said in the FAQ as ashton said
>> > >
>> > > On Sat May 1, 2021 at 6:25 PM CST, Luke Small wrote:
>> > > > I tried that by the way. I even mv’ed my pf.conf to nullify it and
>> > > > tried
>> > > > and it couldn’t download from the gigenet mirror which absolutely
>> has
>> > > > the
>> > > > 6.9 files. It didn’t work at all. Sysupgrade really needs to be able
>> > > > to be
>> > > > working on versions as well as -r and -s! The program isn’t
>> > > > intelligent
>> > > > enough.
>> > > >
>> > > > On Sat, May 1, 2021 at 5:26 PM jpeg bild 
>> wrote:
>> > > >
>> > > > > If you want to move back to stable, you would have to boot bsd.rd
>> and
>> > > > > select "Upgrade" in the prompt, then install from http with the
>> correct
>> > > > > path for 6.9-stable
>> > > > >
>> > > > > On Fri Apr 30, 2021 at 9:49 PM CST, Luke Small wrote:
>> > > > > > We’re there major irreversible changes made to the following
>> > > snapshot:
>> > > > > >
>> > > > > > kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr 26
>> > > 02:26:53
>> > > > > > MDT
>> > > > > > 2021
>> > > > > >
>> > > > > > which would render in incapable of a downgrade?
>> > > > > > --
>> > > > > > -Luke
>> > > > >
>> > > > > --
>> > > > -Luke
>> > >
>> > > --
>> > -Luke
>>
>> --
> -Luke
>
-- 
-Luke


Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-05-02 Thread Luke Small
There has to be a valid partition to install it to. When I have an
encrypted drive, that doesn’t exist using usb…chudazoid.

On Sun, May 2, 2021 at 1:31 PM jpeg bild  wrote:

> No you don't chudazoid, you just select your usb disk with the file sets
> after selecting "disk" as your file location
>
> On Sat May 1, 2021 at 7:37 PM CST, Luke Small wrote:
> > I would do that, but I’ll have to figure out how to manually mount my
> > encrypted partition, which sysupgrade and bsd.rd takes care if for me
> > automatically.
> >
> > On Sat, May 1, 2021 at 8:07 PM jpeg bild  wrote:
> >
> > > Use the fastly mirror, or download the files to a usb stick and select
> > > "disk" at the prompt. once you go current you can't go back, and its
> > > very clearly said in the FAQ as ashton said
> > >
> > > On Sat May 1, 2021 at 6:25 PM CST, Luke Small wrote:
> > > > I tried that by the way. I even mv’ed my pf.conf to nullify it and
> > > > tried
> > > > and it couldn’t download from the gigenet mirror which absolutely has
> > > > the
> > > > 6.9 files. It didn’t work at all. Sysupgrade really needs to be able
> > > > to be
> > > > working on versions as well as -r and -s! The program isn’t
> > > > intelligent
> > > > enough.
> > > >
> > > > On Sat, May 1, 2021 at 5:26 PM jpeg bild 
> wrote:
> > > >
> > > > > If you want to move back to stable, you would have to boot bsd.rd
> and
> > > > > select "Upgrade" in the prompt, then install from http with the
> correct
> > > > > path for 6.9-stable
> > > > >
> > > > > On Fri Apr 30, 2021 at 9:49 PM CST, Luke Small wrote:
> > > > > > We’re there major irreversible changes made to the following
> > > snapshot:
> > > > > >
> > > > > > kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr 26
> > > 02:26:53
> > > > > > MDT
> > > > > > 2021
> > > > > >
> > > > > > which would render in incapable of a downgrade?
> > > > > > --
> > > > > > -Luke
> > > > >
> > > > > --
> > > > -Luke
> > >
> > > --
> > -Luke
>
> --
-Luke


Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-05-01 Thread Luke Small
I would do that, but I’ll have to figure out how to manually mount my
encrypted partition, which sysupgrade and bsd.rd takes care if for me
automatically.

On Sat, May 1, 2021 at 8:07 PM jpeg bild  wrote:

> Use the fastly mirror, or download the files to a usb stick and select
> "disk" at the prompt. once you go current you can't go back, and its
> very clearly said in the FAQ as ashton said
>
> On Sat May 1, 2021 at 6:25 PM CST, Luke Small wrote:
> > I tried that by the way. I even mv’ed my pf.conf to nullify it and
> > tried
> > and it couldn’t download from the gigenet mirror which absolutely has
> > the
> > 6.9 files. It didn’t work at all. Sysupgrade really needs to be able
> > to be
> > working on versions as well as -r and -s! The program isn’t
> > intelligent
> > enough.
> >
> > On Sat, May 1, 2021 at 5:26 PM jpeg bild  wrote:
> >
> > > If you want to move back to stable, you would have to boot bsd.rd and
> > > select "Upgrade" in the prompt, then install from http with the correct
> > > path for 6.9-stable
> > >
> > > On Fri Apr 30, 2021 at 9:49 PM CST, Luke Small wrote:
> > > > We’re there major irreversible changes made to the following
> snapshot:
> > > >
> > > > kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr 26
> 02:26:53
> > > > MDT
> > > > 2021
> > > >
> > > > which would render in incapable of a downgrade?
> > > > --
> > > > -Luke
> > >
> > > --
> > -Luke
>
> --
-Luke


Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-05-01 Thread Luke Small
I thought I’d be nice and try the beta to help out, but if the ramdisk
doesn’t even work anymore like it has in the past for me, I’m just going
from 6.9-current to 7.0-stable and never looking back at trying current
anymore. I could try sysupgrade -n and download the requisite 6.9-release
files to replace them, but I’m too worried it’d be messed in some way and
brick my machine.

I have a simple network setup of google fiber with a modem/router at
196.168.1.1 which the default pf.conf should work instead of my pretty
complicated (for a home network) pf.conf . I have no clue why the bsd.rd
doesn’t work anymore…unless the dhclient.conf which I’ve told to listen to
localhost for unbound and dnscrypt-proxy is gumming things up.

I sure wish sysupgrade was more reasonable.

Even pkg_add permits “downgrade”

On Sat, May 1, 2021 at 7:51 PM Theo de Raadt  wrote:

> The FAQ speaks to this matter.
>
> Noone else has anything more to say.
>
> Please stop begging for personal handholding, everyone is getting
> embarrassed.
>
>
>
> Luke Small  wrote:
>
> > I tried that by the way. I even mv’ed my pf.conf to nullify it and tried
> > and it couldn’t download from the gigenet mirror which absolutely has the
> > 6.9 files. It didn’t work at all. Sysupgrade really needs to be able to
> be
> > working on versions as well as -r and -s! The program isn’t intelligent
> > enough.
> >
> > On Sat, May 1, 2021 at 5:26 PM jpeg bild  wrote:
> >
> > > If you want to move back to stable, you would have to boot bsd.rd and
> > > select "Upgrade" in the prompt, then install from http with the correct
> > > path for 6.9-stable
> > >
> > > On Fri Apr 30, 2021 at 9:49 PM CST, Luke Small wrote:
> > > > We’re there major irreversible changes made to the following
> snapshot:
> > > >
> > > > kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr 26
> 02:26:53
> > > > MDT
> > > > 2021
> > > >
> > > > which would render in incapable of a downgrade?
> > > > --
> > > > -Luke
> > >
> > > --
> > -Luke
>
-- 
-Luke


Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-05-01 Thread Luke Small
I tried that by the way. I even mv’ed my pf.conf to nullify it and tried
and it couldn’t download from the gigenet mirror which absolutely has the
6.9 files. It didn’t work at all. Sysupgrade really needs to be able to be
working on versions as well as -r and -s! The program isn’t intelligent
enough.

On Sat, May 1, 2021 at 5:26 PM jpeg bild  wrote:

> If you want to move back to stable, you would have to boot bsd.rd and
> select "Upgrade" in the prompt, then install from http with the correct
> path for 6.9-stable
>
> On Fri Apr 30, 2021 at 9:49 PM CST, Luke Small wrote:
> > We’re there major irreversible changes made to the following snapshot:
> >
> > kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr 26 02:26:53
> > MDT
> > 2021
> >
> > which would render in incapable of a downgrade?
> > --
> > -Luke
>
> --
-Luke


Re: Can I do 4-26 snapshot to 6.9-stable safely?

2021-05-01 Thread Luke Small
I google searched: “site:openbsd.org (snapshot OR current) (stable OR
release) faq”

and found no results which speaks of minor downgrades.

Also, “sysupgrade -r” defaults to 7.0 when trying to upgrade from previous
6.9 snapshots to release. Is it intended to require folks to use bsd.rd (or
use an iso) to make that change?

On Fri, Apr 30, 2021 at 11:01 PM Theo de Raadt  wrote:

> Luke Small  wrote:
>
> > We’re there major irreversible changes made to the following snapshot:
> >
> > kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr 26 02:26:53
> MDT
> > 2021
> >
> > which would render in incapable of a downgrade?
>
> The FAQ has a clear & simple answer to that question, and it is our
> belief that noone deserves an independently decided answer on a
> case-by-case basis.  Basically, stop wasting our time.
>
> --
-Luke


Can I do 4-26 snapshot to 6.9-stable safely?

2021-04-30 Thread Luke Small
We’re there major irreversible changes made to the following snapshot:

kern.version=OpenBSD 6.9-current (GENERIC.MP) #479: Mon Apr 26 02:26:53 MDT
2021

which would render in incapable of a downgrade?
-- 
-Luke


Can I shorten fw_update download timeout?

2021-04-08 Thread Luke Small
I make unbound connect to dnscrypt-proxy and after an update, it’ll just
sit there for what seems like 2 minutes while fw_update inevitably fails
before turning on dnscrypt-proxy. I’ve been running snapshots and that’s
really dumb. Or is there a way to have unbound connect to a failover server
when the default resolver isn’t responsive that I’m not aware of?--
-Luke


Re: FVWM terminal emulator transparency issue in -current

2021-02-17 Thread Luke Small
Thanks! I just made it run at opacity .55 and I LOVE IT! Thanks!

On Mon, Feb 15, 2021 at 11:25 PM Thomas Frohwein 
wrote:

> On Mon, Feb 15, 2021 at 05:03:55PM -0600, Luke Small wrote:
> > I'm running fvwm window manager and I just switched to -current. Roxterm
> is
> > totally messed up, won't do transparent background and I tried
> > xfce4-terminal and it says it won't do transparent backgrounds because
> > compositing is disabled Sure first-world problems, but I REALLY want
> > fvwm to do transparent terminal emulators!
>
> You can just run a compositor. xcompmgr(1) is in the X install. I
> personally
> use compton from the package of the same name. picom (also in packages) is
> supposed to be a successor to compton. They allow more compositor tricks
> than xompmgr.
>
> I've never got application's transparency settings to work well, so my
> .kshrc (set in ENV in .profile) contains lines calling transset-df from
> the package of the same name:
>
> [ -n "$XTERM_VERSION" ] && transset-df --id "$WINDOWID" 0.85 > /dev/null
> [ -n "$KITTY_WINDOW_ID" ] && transset-df --id "$WINDOWID" 0.85 > /dev/null
>


FVWM terminal emulator transparency issue in -current

2021-02-15 Thread Luke Small
I'm running fvwm window manager and I just switched to -current. Roxterm is
totally messed up, won't do transparent background and I tried
xfce4-terminal and it says it won't do transparent backgrounds because
compositing is disabled Sure first-world problems, but I REALLY want
fvwm to do transparent terminal emulators!

-Luke


Snort for httpd’s https sessions?!

2021-01-06 Thread Luke Small
Is there a way for a hook(?) for snort to read plaintext https sessions in
OpenBSD’s httpd?! That’d be SUPER SWEET!--
-Luke


pf and Wireguard

2020-09-26 Thread Luke Small
...

Change:

match out on egress from (wg0:network) to any nat-to (egress:0)

To:
match on egress from (wg0:network) to any nat-to (egress:0) tag “wireguard”

pass tagged “wireguard” keep state

-- 
-Luke


USA kernel hackers looking for a $120k+ job?

2020-08-18 Thread Luke Small
I’m applying for federal grant which will hopefully start about March or
April and I’m looking for somebody who can work on OpenBSD and in C
(perhaps with a touch of python) to do the server side of an extraordinary
dating app which will be able to prove STD uninfectiousness!
-- 
-Luke


fullscreen iridium stops me scrolling to another fvwm virt. desktop!

2020-07-14 Thread Luke Small
fullscreen iridium browser often stops letting me scroll to another fvwm
virtual desktop, but I never have that problem with firefox! Whats the
deal? On iridium, I either have to click on the browser window border or I
have to unmaximize the browser window to leave space between the browser
window and the virtual desktop border.
-Luke


Re: strlcpy version speed tests?

2020-07-01 Thread Luke Small
Are you clinging to traditions for some purpose? I gave two different
versions. strlcpy3 is clearly more easily understood and even slightly
faster and strlcpy4 which sets up the following workhorse lines which
through timing the functions is hands down faster on my Xeon chips:


strlcpy4:
while (--nleft != 0)
 if ((*++dst = *++src) == '\0')
...

the others:

while (--nleft != 0)
  if ((*dst++ = *src++) == '\0')

...


I spoke to my favorite university computer science professor who said
++n is faster than n++ because the function needs to store the initial
value, increment, then return the

stored value in the former case,

while the later merely increments, and returns the value. Apparently,
he is still correct on modern hardware.

-- 
-Luke


Re: strlcpy version speed tests?

2020-06-30 Thread Luke Small
I suppose this strlcpy4 without a goto is more elegant
-Luke


On Tue, Jun 30, 2020 at 10:07 PM Luke Small  wrote:

> I made it SUPER easy to test my assertion. The code is there. No
> configuration needed.
>
> On Tue, Jun 30, 2020 at 9:59 PM Theo de Raadt  wrote:
>
>> Luke Small  wrote:
>>
>> > So did you run the program on one of those?
>>
>> Why would I?
>>
>> i see a sales pitch
>>
>> and i go BULLSHIT
>>
>> and I'm done
>>
>> --
> -Luke
>
#include 
#include 
#include 
#include 
#include 
#include 

/* cc strlcpy_test.c -pipe -O2 -o strlcpy_test && ./strlcpy_testfast */

/*
 * Copy string src to buffer dst of size dsize.  At most dsize-1
 * chars will be copied.  Always NUL terminates (unless dsize == 0).
 * Returns strlen(src); if retval >= dsize, truncation occurred.
 */
static size_t
strlcpy0(char *dst, const char *src, size_t dsize)
{
	const char *osrc = src;
	size_t nleft = dsize;

	/* Copy as many bytes as will fit. */
	if (nleft != 0) {
		while (--nleft != 0) {
			if ((*dst++ = *src++) == '\0')
break;
		}
	}

	/* Not enough room in dst, add NUL and traverse rest of src. */
	if (nleft == 0) {
		if (dsize != 0)
			*dst = '\0';		/* NUL-terminate dst */
		while (*src++)
			;
	}

	return(src - osrc - 1);	/* count does not include NUL */
}

static size_t
strlcpy3(char *dst, const char *src, size_t dsize)
{
	const char *osrc = src;
	size_t nleft = dsize;

	if (nleft != 0) {
		/* Copy as many bytes as will fit. */
		while (--nleft != 0)
			if ((*dst++ = *src++) == '\0')
return(src - osrc - 1);
		*dst = '\0';
	}
	
	/* Not enough room in dst, traverse rest of src. */
	while (*src++)
			;

	return(src - osrc - 1);	/* count does not include NUL */
}

static size_t
strlcpy4(char dst[], const char src[], size_t dsize)
{
	const char *osrc = src;
	size_t nleft = dsize;

	if (nleft != 0) {
		if (--nleft == 0) {
			*dst = '\0';	/* NUL-terminate dst */
			if (*src == '\0')
return 0;
		} else {
			/* Copy as many bytes as will fit. */
			if ((*dst = *src) == '\0')
return 0;
			while (--nleft != 0)
if ((*++dst = *++src) == '\0')
	return(src - osrc);
			dst[1] = '\0';	/* NUL-terminate dst */
		}
	} else if (*src == '\0')
		return 0;
	
	/* Not enough room in dst, traverse rest of src. */
	while (*++src)
			;
	

	return(src - osrc);	/* count does not include NUL */
}


int main()
{

	long double cpu_time_used;
	size_t y;
	struct timespec tv_start, tv_end;
	char *buffer, *buffer2;
	
	size_t n = 5;
	size_t m = n + 50;
	
	buffer = malloc(m);
	if (buffer == NULL) err(1, "malloc");
	buffer2 = malloc(n);
	if (buffer2 == NULL) err(1, "malloc");
	
	
	/* no intermediate '\0' */
	for (y = 0; y < m; ++y)
		buffer[y] = arc4random_uniform(255) + 1;
	buffer[m - 1] = '\0';




	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _start);
	strlcpy(buffer2, buffer, n);
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _end);

	cpu_time_used =
	(long double) (tv_end.tv_sec - tv_start.tv_sec) +
	(long double) (tv_end.tv_nsec - tv_start.tv_nsec) /
	(long double) 10;

	printf("\n\nstrlcpy\n");
	printf("time = %.9Lf\n\n\n", cpu_time_used);




	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _start);
	strlcpy0(buffer2, buffer, n);
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _end);

	cpu_time_used =
	(long double) (tv_end.tv_sec - tv_start.tv_sec) +
	(long double) (tv_end.tv_nsec - tv_start.tv_nsec) /
	(long double) 10;

	printf("\n\nstrlcpy0\n");
	printf("time = %.9Lf\n\n\n", cpu_time_used);





	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _start);
	strlcpy3(buffer2, buffer, n);
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _end);

	cpu_time_used =
	(long double) (tv_end.tv_sec - tv_start.tv_sec) +
	(long double) (tv_end.tv_nsec - tv_start.tv_nsec) /
	(long double) 10;

	printf("\n\nstrlcpy3\n");
	printf("time = %.9Lf\n\n\n", cpu_time_used);





	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _start);
	strlcpy4(buffer2, buffer, n);
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _end);

	cpu_time_used =
	(long double) (tv_end.tv_sec - tv_start.tv_sec) +
	(long double) (tv_end.tv_nsec - tv_start.tv_nsec) /
	(long double) 10;

	printf("\n\nstrlcpy4\n");
	printf("time = %.9Lf\n\n\n", cpu_time_used);



	return 0;
}


strlcpy version speed tests?

2020-06-30 Thread Luke Small
I made a couple different versions if anybody is interested!
-Luke
#include 
#include 
#include 
#include 
#include 
#include 

/* cc strlcpy_test.c -pipe -O2 -o strlcpy_test && ./strlcpy_testfast */

/*
 * Copy string src to buffer dst of size dsize.  At most dsize-1
 * chars will be copied.  Always NUL terminates (unless dsize == 0).
 * Returns strlen(src); if retval >= dsize, truncation occurred.
 */
static size_t
strlcpy0(char *dst, const char *src, size_t dsize)
{
	const char *osrc = src;
	size_t nleft = dsize;

	/* Copy as many bytes as will fit. */
	if (nleft != 0) {
		while (--nleft != 0) {
			if ((*dst++ = *src++) == '\0')
break;
		}
	}

	/* Not enough room in dst, add NUL and traverse rest of src. */
	if (nleft == 0) {
		if (dsize != 0)
			*dst = '\0';		/* NUL-terminate dst */
		while (*src++)
			;
	}

	return(src - osrc - 1);	/* count does not include NUL */
}

static size_t
strlcpy3(char *dst, const char *src, size_t dsize)
{
	const char *osrc = src;
	size_t nleft = dsize;

	if (nleft != 0) {
		/* Copy as many bytes as will fit. */
		while (--nleft != 0)
			if ((*dst++ = *src++) == '\0')
return(src - osrc - 1);
		*dst = '\0';
	}
	
	/* Not enough room in dst, traverse rest of src. */
	while (*src++)
			;

	return(src - osrc - 1);	/* count does not include NUL */
}

static size_t
strlcpy4(char dst[], const char src[], size_t dsize)
{
	const char *osrc = src;
	size_t nleft = dsize;

	if (nleft != 0) {
		if (--nleft == 0)
		{
			*dst = '\0';
			if (*src == '\0')
return 0;
			goto strlcpy_jump;
		}
		/* Copy as many bytes as will fit. */
		if ((*dst = *src) == '\0')
			return 0;
		while (--nleft != 0)
			if ((*++dst = *++src) == '\0')
return(src - osrc);
		dst[1] = '\0';	/* NUL-terminate dst */
	} else if (*src == '\0')
		return 0;
	
	strlcpy_jump:
	
	/* Not enough room in dst, traverse rest of src. */
	while (*++src)
			;
	

	return(src - osrc);	/* count does not include NUL */
}


int main()
{

	long double cpu_time_used;
	size_t y;
	struct timespec tv_start, tv_end;
	char *buffer, *buffer2;
	
	size_t n = 5;
	size_t m = n + 500;
	
	buffer = malloc(m);
	if (buffer == NULL) err(1, "malloc");
	buffer2 = malloc(n);
	if (buffer2 == NULL) err(1, "malloc");
	
	
	/* no intermediate '\0' */
	for (y = 0; y < m; ++y)
		buffer[y] = arc4random_uniform(255) + 1;
	buffer[m - 1] = '\0';




	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _start);
	strlcpy(buffer2, buffer, n);
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _end);

	cpu_time_used =
	(long double) (tv_end.tv_sec - tv_start.tv_sec) +
	(long double) (tv_end.tv_nsec - tv_start.tv_nsec) /
	(long double) 10;

	printf("\n\nstrlcpy\n");
	printf("time = %.9Lf\n\n\n", cpu_time_used);




	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _start);
	strlcpy0(buffer2, buffer, n);
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _end);

	cpu_time_used =
	(long double) (tv_end.tv_sec - tv_start.tv_sec) +
	(long double) (tv_end.tv_nsec - tv_start.tv_nsec) /
	(long double) 10;

	printf("\n\nstrlcpy0\n");
	printf("time = %.9Lf\n\n\n", cpu_time_used);





	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _start);
	strlcpy3(buffer2, buffer, n);
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _end);

	cpu_time_used =
	(long double) (tv_end.tv_sec - tv_start.tv_sec) +
	(long double) (tv_end.tv_nsec - tv_start.tv_nsec) /
	(long double) 10;

	printf("\n\nstrlcpy3 \n");
	printf("time = %.9Lf\n\n\n", cpu_time_used);





	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _start);
	strlcpy4(buffer2, buffer, n);
	clock_gettime(CLOCK_PROCESS_CPUTIME_ID, _end);

	cpu_time_used =
	(long double) (tv_end.tv_sec - tv_start.tv_sec) +
	(long double) (tv_end.tv_nsec - tv_start.tv_nsec) /
	(long double) 10;

	printf("\n\nstrlcpy4 \n");
	printf("time = %.9Lf\n\n\n", cpu_time_used);



	return 0;
}


why isn't strlcpy written like this:

2020-06-30 Thread Luke Small
strlcpy is:

size_t
strlcpy(char *dst, const char *src, size_t dsize)
{
  const char *osrc = src;
  size_t nleft = dsize;

  /* Copy as many bytes as will fit. */
  if (nleft != 0) {
  while (--nleft != 0) {
if ((*dst++ = *src++) == '\0')
  break;
  }
}

/* Not enough room in dst, add NUL and traverse rest of src. */
  if (nleft == 0) {
if (dsize != 0)
  *dst = '\0'; /* NUL-terminate dst */
while (*src++)
   ;
}

  return(src - osrc - 1); /* count does not include NUL */
}



why isn't it like this (this version is faster too):

size_t
strlcpy2(char *dst, const char *src, size_t dsize)
{
  const char *osrc = src;

  if (dsize != 0) {
/* Copy as many bytes as will fit. */
while (--dsize != 0)
  if ((*dst++ = *src++) == '\0')
return(src - osrc - 1);
*dst = '\0';
  }

  /* Not enough room in dst, traverse rest of src. */
  while (*src++)
   ;

  return(src - osrc - 1); /* count does not include NUL */
}



-Luke


Re: Filling a 4TB Disk with Random Data

2020-06-10 Thread Luke Small
if you have access to packages, you could "pkg_add pv"

and:

"dd if=/dev/random | pv | dd of=/dev/rsdXc bs=1m"

It will show you in real time how much random

data has been written to disk.

-Luke


On Wed, Jun 10, 2020 at 11:43 AM Luke Small  wrote:

> I mean: "dd if=/dev/random | pv | dd of=/dev/rsdXc bs=1m"
>
> -Luke
>
>
> On Wed, Jun 10, 2020 at 11:41 AM Luke Small  wrote:
>
>> if you have access to packages, you could "pkg_add pv"
>>
>> and:
>>
>> "dd if=/dev/random | pv | of=/dev/rsdXc bs=1m"
>>
>> It will show you in real time how much random
>>
>> data has been written to disk.
>>
>> -Luke
>>
>


realpath(3) to unveil() symbolic links!

2020-06-04 Thread Luke Small
You can use unveil() on both a symbolic link and the value recovered by
putting it in realpath(3)! I used it in what I submitted for unveiling
ftp(1)
-- 
-Luke


Re: I unveil()ed ftp(1)!

2020-06-04 Thread Luke Small
I made symbolic links “ln -s /etc/ssl/cert.pem ”. I used the
realpath command and it worked in the software I submitted.

On Thu, Jun 4, 2020 at 11:06 AM Theo de Raadt  wrote:

> No.
>
> I'm guessing you don't understand symbolic links.
>
> Look, this is a waste of time.
>
>
> Luke Small  wrote:
>
> > --80daf105a7444c30
> > Content-Type: text/plain; charset="UTF-8"
> > Content-Transfer-Encoding: 8bit
> >
> > In the case of 1 URLs couldn’t you at least merely unveil “./“ as
> “cw”;
> > make any specified cafile/capath including shortcut resolution as “r”
> > (perhaps with the shell “x”) so that at worst, current directory files
> > could be overwritten, but not read?
> >
> > On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt 
> wrote:
> >
> > > You really don't get it.
> > >
> > > +   unveil_list = calloc(2 * argc, sizeof(char*));
> > >
> > > Imagine argc is 1.
> > >
> > > +   for (i = 2 * argc - 2; i >= 0; i -= 2) {
> > > +   if (unveil_list[i]) {
> > > +   if (unveil(unveil_list[i],
> "r") ==
> > > -1)
> > > ...
> > > +   if (unveil_list[i | 1]) {
> > > +   if (unveil(unveil_list[i | 1],
> > > "cw") == -1)
> > > +   err(1, "unveil");
> > > ...
> > >
> > >
> > >  E2BIG  The addition of path would exceed the
> per-process
> > > limit for unveiled paths.
> > >
> > >
> > > Great, under fairly normal usage ftp aborts with an error.
> > >
> > > Since you start with up to 8 others, it looks like this limit is easily
> > > hit at around 120 filenames.
> > >
> > > So ftp simply fails to perform the task it is designed for.
> > >
> > > Your proposal is to break the command.
> > >
> > > --
> > -Luke
> >
> > --80daf105a7444c30
> > Content-Type: text/html; charset="UTF-8"
> > Content-Transfer-Encoding: 8bit
> >
> > In the case of 1 URLs couldn’t you at least
> merely unveil “./“ as “cw”; make any specified cafile/capath including
> shortcut resolution as “r” (perhaps with the shell “x”) so that at worst,
> current directory files could be overwritten, but not
> read? class="gmail_attr">On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt  href="mailto:dera...@openbsd.org;>dera...@openbsd.org
> wrote:You
> really dont get it.
> > 
> > +   unveil_list = calloc(2 * argc,
> sizeof(char*));
> > 
> > Imagine argc is 1.
> > 
> > +   for (i = 2 * argc - 2; i = 0; i -= 2) {
> > +   if (unveil_list[i]) {
> > +   if (unveil(unveil_list[i],
> r) == -1)
> > ...
> > +   if (unveil_list[i | 1]) {
> > +   if (unveil(unveil_list[i | 1],
> cw) == -1)
> > +   err(1,
> unveil);
> > ...
> > 
> > 
> >  E2BIG  The addition of path would exceed the
> per-process
> > limit for unveiled paths.
> > 
> > 
> > Great, under fairly normal usage ftp aborts with an error.  
> > 
> > Since you start with up to 8 others, it looks like this limit is
> easily
> > hit at around 120 filenames.
> > 
> > So ftp simply fails to perform the task it is designed for.
> > 
> > Your proposal is to break the command.
> > 
> > --  data-smartmail="gmail_signature">-Luke
> >
> > --80daf105a7444c30--
>
-- 
-Luke


Re: I unveil()ed ftp(1)!

2020-06-04 Thread Luke Small
In the case of 1 URLs couldn’t you at least merely unveil “./“ as “cw”;
make any specified cafile/capath including shortcut resolution as “r”
(perhaps with the shell “x”) so that at worst, current directory files
could be overwritten, but not read?

On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt  wrote:

> You really don't get it.
>
> +   unveil_list = calloc(2 * argc, sizeof(char*));
>
> Imagine argc is 1.
>
> +   for (i = 2 * argc - 2; i >= 0; i -= 2) {
> +   if (unveil_list[i]) {
> +   if (unveil(unveil_list[i], "r") ==
> -1)
> ...
> +   if (unveil_list[i | 1]) {
> +   if (unveil(unveil_list[i | 1],
> "cw") == -1)
> +   err(1, "unveil");
> ...
>
>
>  E2BIG  The addition of path would exceed the per-process
> limit for unveiled paths.
>
>
> Great, under fairly normal usage ftp aborts with an error.
>
> Since you start with up to 8 others, it looks like this limit is easily
> hit at around 120 filenames.
>
> So ftp simply fails to perform the task it is designed for.
>
> Your proposal is to break the command.
>
> --
-Luke


Re: I unveil()ed ftp(1)!

2020-06-03 Thread Luke Small
there was tiny error I created.
-Luke


On Wed, Jun 3, 2020 at 2:24 PM Luke Small  wrote:

> There! It doesn't use an unveil list. It has 2 dry runs as proposed.
> It could just have a dry run to see if it goes into interactive mode
> and then unveil as we go! but I like to see all the unveil calls before
> the ftp output statements myself!
> -Luke
>
>
> On Wed, Jun 3, 2020 at 11:30 AM Luke Small  wrote:
>
>> Or you could have 2 dry runs. One to merely see that it won't head into
>> interactive mode
>> and a second one to start the unveiling directly in fetch.c. Unless
>> unveil itself will
>> have too many entries!
>> -Luke
>>
>>
>> On Wed, Jun 3, 2020 at 11:12 AM Luke Small  wrote:
>>
>>> I figure if it took up that much stack space from before, it'd start
>>> needing to
>>> dang near run the stack into on-disk virtual memory anyway. At that
>>> point,
>>> it'd perhaps be a better design choice to break up your ftp calls into
>>> slightly
>>> smaller chunks to avoid massively poor performance, yeah? LOL
>>>
>>> If you're really worried about it, perhaps you could put in a goto which
>>> jumps
>>> over the offending part, when argc is so massive that
>>> it would cause such a thing...Hmmm.
>>> -Luke
>>>
>>>
>>> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt 
>>> wrote:
>>>
>>>> You really don't get it.
>>>>
>>>> +   unveil_list = calloc(2 * argc, sizeof(char*));
>>>>
>>>> Imagine argc is 1.
>>>>
>>>> +   for (i = 2 * argc - 2; i >= 0; i -= 2) {
>>>> +   if (unveil_list[i]) {
>>>> +   if (unveil(unveil_list[i], "r")
>>>> == -1)
>>>> ...
>>>> +   if (unveil_list[i | 1]) {
>>>> +   if (unveil(unveil_list[i | 1],
>>>> "cw") == -1)
>>>> +   err(1, "unveil");
>>>> ...
>>>>
>>>>
>>>>  E2BIG  The addition of path would exceed the
>>>> per-process
>>>> limit for unveiled paths.
>>>>
>>>>
>>>> Great, under fairly normal usage ftp aborts with an error.
>>>>
>>>> Since you start with up to 8 others, it looks like this limit is easily
>>>> hit at around 120 filenames.
>>>>
>>>> So ftp simply fails to perform the task it is designed for.
>>>>
>>>> Your proposal is to break the command.
>>>>
>>>>
Common subdirectories: /usr/src/usr.bin/ftp/CVS and /home/luke/ftp/CVS
diff -uNp /usr/src/usr.bin/ftp/extern.h /home/luke/ftp/extern.h
--- /usr/src/usr.bin/ftp/extern.h	Thu May 16 07:44:17 2019
+++ /home/luke/ftp/extern.h	Wed Jun  3 13:41:49 2020
@@ -69,6 +69,7 @@ void	abortrecv(int);
 void	alarmtimer(int);
 int	another(int *, char ***, const char *);
 int	auto_fetch(int, char **, char *);
+int	auto_fetch_u(int, char **, char *, int, int);
 void	blkfree(char **);
 void	cdup(int, char **);
 void	cmdabort(int);
diff -uNp /usr/src/usr.bin/ftp/fetch.c /home/luke/ftp/fetch.c
--- /usr/src/usr.bin/ftp/fetch.c	Fri Feb 21 19:00:07 2020
+++ /home/luke/ftp/fetch.c	Wed Jun  3 15:51:45 2020
@@ -68,8 +68,10 @@ struct tls;
 #include "ftp_var.h"
 #include "cmds.h"
 
-static int	file_get(const char *, const char *);
+//~ static int	file_get(const char *, const char *);
+static int	file_get_u(const char *, const char *, int, int);
 static int	url_get(const char *, const char *, const char *, int);
+static int	url_get_u(const char *, const char *, const char *, int, int, int);
 static int	save_chunked(FILE *, struct tls *, int , char *, size_t);
 static void	aborthttp(int);
 static void	abortfile(int);
@@ -186,8 +188,14 @@ tooslow(int signo)
  * Copy a local file (used by the OpenBSD installer).
  * Returns -1 on failure, 0 on success
  */
+//~ static int
+//~ file_get(const char *path, const char *outfile)
+//~ {
+	//~ return file_get_u(path, outfile, 1, 0);
+//~ }
+	
 static int
-file_get(const char *path, const char *outfile)
+file_get_u(const char *path, const char *outfile, int ready, int tout)
 {
 	struct stat	 st;
 	int		 fd, out, rval = -1, save_errno;
@@ -200,17 +208,28 @@ file_get(const char *path, const char *outfile)
 
 	direction = "received";
 
-	fd = open(path, O_RDONLY);
-	if (fd == -1) {
-		warn("Can't open file %s", path);
-		return -1;
-	}
+	if (ready) {
+		
+

Re: I unveil()ed ftp(1)!

2020-06-03 Thread Luke Small
There! It doesn't use an unveil list. It has 2 dry runs as proposed.
It could just have a dry run to see if it goes into interactive mode
and then unveil as we go! but I like to see all the unveil calls before
the ftp output statements myself!
-Luke


On Wed, Jun 3, 2020 at 11:30 AM Luke Small  wrote:

> Or you could have 2 dry runs. One to merely see that it won't head into
> interactive mode
> and a second one to start the unveiling directly in fetch.c. Unless unveil
> itself will
> have too many entries!
> -Luke
>
>
> On Wed, Jun 3, 2020 at 11:12 AM Luke Small  wrote:
>
>> I figure if it took up that much stack space from before, it'd start
>> needing to
>> dang near run the stack into on-disk virtual memory anyway. At that point,
>> it'd perhaps be a better design choice to break up your ftp calls into
>> slightly
>> smaller chunks to avoid massively poor performance, yeah? LOL
>>
>> If you're really worried about it, perhaps you could put in a goto which
>> jumps
>> over the offending part, when argc is so massive that
>> it would cause such a thing...Hmmm.
>> -Luke
>>
>>
>> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt 
>> wrote:
>>
>>> You really don't get it.
>>>
>>> +   unveil_list = calloc(2 * argc, sizeof(char*));
>>>
>>> Imagine argc is 1.
>>>
>>> +   for (i = 2 * argc - 2; i >= 0; i -= 2) {
>>> +   if (unveil_list[i]) {
>>> +   if (unveil(unveil_list[i], "r")
>>> == -1)
>>> ...
>>> +   if (unveil_list[i | 1]) {
>>> +   if (unveil(unveil_list[i | 1],
>>> "cw") == -1)
>>> +   err(1, "unveil");
>>> ...
>>>
>>>
>>>  E2BIG  The addition of path would exceed the per-process
>>> limit for unveiled paths.
>>>
>>>
>>> Great, under fairly normal usage ftp aborts with an error.
>>>
>>> Since you start with up to 8 others, it looks like this limit is easily
>>> hit at around 120 filenames.
>>>
>>> So ftp simply fails to perform the task it is designed for.
>>>
>>> Your proposal is to break the command.
>>>
>>>
/*	$OpenBSD: fetch.c,v 1.194 2020/02/22 01:00:07 jca Exp $	*/
/*	$NetBSD: fetch.c,v 1.14 1997/08/18 10:20:20 lukem Exp $	*/

/*-
 * Copyright (c) 1997 The NetBSD Foundation, Inc.
 * All rights reserved.
 *
 * This code is derived from software contributed to The NetBSD Foundation
 * by Jason Thorpe and Luke Mewburn.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.
 */

/*
 * FTP User Program -- Command line file retrieval
 */

#include 
#include 
#include 

#include 

#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifndef NOSSL
#include 
#else /* !NOSSL */
struct tls;
#endif /* !NOSSL */

#include "ftp_var.h"
#include "cmds.h"

//~ static int	file_get(const char *, const char *);
static int	file_get_u(const char *, const char *, int, int);
static int	url_get(const char *, const char *, const char *, int);
static int	url_get_u(const char *, const char *, const char *, int, int, int);
static int	save_chunked(FILE *, struct 

Re: I unveil()ed ftp(1)!

2020-06-03 Thread Luke Small
Or you could have 2 dry runs. One to merely see that it won't head into
interactive mode
and a second one to start the unveiling directly in fetch.c. Unless unveil
itself will
have too many entries!
-Luke


On Wed, Jun 3, 2020 at 11:12 AM Luke Small  wrote:

> I figure if it took up that much stack space from before, it'd start
> needing to
> dang near run the stack into on-disk virtual memory anyway. At that point,
> it'd perhaps be a better design choice to break up your ftp calls into
> slightly
> smaller chunks to avoid massively poor performance, yeah? LOL
>
> If you're really worried about it, perhaps you could put in a goto which
> jumps
> over the offending part, when argc is so massive that
> it would cause such a thing...Hmmm.
> -Luke
>
>
> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt  wrote:
>
>> You really don't get it.
>>
>> +   unveil_list = calloc(2 * argc, sizeof(char*));
>>
>> Imagine argc is 1.
>>
>> +   for (i = 2 * argc - 2; i >= 0; i -= 2) {
>> +   if (unveil_list[i]) {
>> +   if (unveil(unveil_list[i], "r")
>> == -1)
>> ...
>> +   if (unveil_list[i | 1]) {
>> +   if (unveil(unveil_list[i | 1],
>> "cw") == -1)
>> +   err(1, "unveil");
>> ...
>>
>>
>>  E2BIG  The addition of path would exceed the per-process
>> limit for unveiled paths.
>>
>>
>> Great, under fairly normal usage ftp aborts with an error.
>>
>> Since you start with up to 8 others, it looks like this limit is easily
>> hit at around 120 filenames.
>>
>> So ftp simply fails to perform the task it is designed for.
>>
>> Your proposal is to break the command.
>>
>>


Re: I unveil()ed ftp(1)!

2020-06-03 Thread Luke Small
I figure if it took up that much stack space from before, it'd start
needing to
dang near run the stack into on-disk virtual memory anyway. At that point,
it'd perhaps be a better design choice to break up your ftp calls into
slightly
smaller chunks to avoid massively poor performance, yeah? LOL

If you're really worried about it, perhaps you could put in a goto which
jumps
over the offending part, when argc is so massive that
it would cause such a thing...Hmmm.
-Luke


On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt  wrote:

> You really don't get it.
>
> +   unveil_list = calloc(2 * argc, sizeof(char*));
>
> Imagine argc is 1.
>
> +   for (i = 2 * argc - 2; i >= 0; i -= 2) {
> +   if (unveil_list[i]) {
> +   if (unveil(unveil_list[i], "r") ==
> -1)
> ...
> +   if (unveil_list[i | 1]) {
> +   if (unveil(unveil_list[i | 1],
> "cw") == -1)
> +   err(1, "unveil");
> ...
>
>
>  E2BIG  The addition of path would exceed the per-process
> limit for unveiled paths.
>
>
> Great, under fairly normal usage ftp aborts with an error.
>
> Since you start with up to 8 others, it looks like this limit is easily
> hit at around 120 filenames.
>
> So ftp simply fails to perform the task it is designed for.
>
> Your proposal is to break the command.
>
>


Re: I unveil()ed ftp(1)!

2020-06-03 Thread Luke Small
I’ll be the first to admit that I don’t completely understand the power
that is the ftp client. but what I do understand of it, from the
perspective of noninteractive commandline execution, it seems to fit the
bill. For file and http(s) transfers. I didn’t see any buffer overflows and
I’m sure that my solution would’ve thrown some segfaults if it had overrun
a buffer in my testing. All the comments like how I needed to resolve soft
links of cafile have been dealt with, but I’m not shy about putting in
single letter variables to perform nested looping. But it seems that the
task that said couldn’t be done, was done. It adds complexity that I’m sure
you aren’t comfortable with; especially since your name is on the file as
the last author, but you can’t say I’m not that demandy lazy ass that
didn’t do anything about it now.

On Wed, Jun 3, 2020 at 9:50 AM Theo de Raadt  wrote:

> I mean it is amusing, because this is never going to fly.
>
> This increase in complexity is completely unacceptable, what I see is
> completely amateurish, and I also see overflows, a lack of testing
> for edge conditions, and a lack of attention to how unveil works.
>
>
> Luke Small  wrote:
>
> > You're welcome! I figured you might not want a “massive” diff to cap off
> your day to
> > make a program that you apparently feel is secure enough, but I made
> good that I got
> > off my ass and did something anyway. I’m surprised that you even went to
> the trouble of
> > pledging it myself. It only took 2 or 3 days to figure out what it was
> doing and change
> > it. I left in the fprintf()s to so that I could amuse you.
> >
> > I’m kinda surprised that you didn’t go straight for the “submit a diff.
> Anything you
> > submit will just be rejected anyway!”
> >
> > On Wed, Jun 3, 2020 at 9:39 AM Theo de Raadt 
> wrote:
> >
> >  Thank you for the laugh.
> >
> >  Luke Small  wrote:
> >
> >  > I think I'm done tinkering. try these out in ftp folder. I left in
> some
> >  > fprintf(ttyout,...) in main.c
> >  > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE
> >  > and SSL_PATH variables.
> >  > It leaves in place the functionality of the original functions, but
> adds
> >  > the availability to perform
> >  > a dry run pass to load an unveil list of potential files from which
> to read
> >  > and create/write.
> >  > The only potential bug is perhaps if in the followup unveiled pass if
> it
> >  > has a problem with dns resolution or
> >  > something, it may be unveiled and drop into a command line. I'm not
> sure.
> >  >
> >  > The diff is of the three files below vs the originals since I last
> updated
> >  > the source files.
> >  >
> >  > -Luke
> >  > --
> >  > -Luke
> >
> > --
> > -Luke
> >
>
-- 
-Luke


Re: I unveil()ed ftp(1)!

2020-06-03 Thread Luke Small
You're welcome! I figured you might not want a “massive” diff to cap off
your day to make a program that you apparently feel is secure enough, but I
made good that I got off my ass and did something anyway. I’m surprised
that you even went to the trouble of pledging it myself. It only took 2 or
3 days to figure out what it was doing and change it. I left in the
fprintf()s to so that I could amuse you.

I’m kinda surprised that you didn’t go straight for the “submit a diff.
Anything you submit will just be rejected anyway!”

On Wed, Jun 3, 2020 at 9:39 AM Theo de Raadt  wrote:

> Thank you for the laugh.
>
>
> Luke Small  wrote:
>
> > I think I'm done tinkering. try these out in ftp folder. I left in some
> > fprintf(ttyout,...) in main.c
> > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE
> > and SSL_PATH variables.
> > It leaves in place the functionality of the original functions, but adds
> > the availability to perform
> > a dry run pass to load an unveil list of potential files from which to
> read
> > and create/write.
> > The only potential bug is perhaps if in the followup unveiled pass if it
> > has a problem with dns resolution or
> > something, it may be unveiled and drop into a command line. I'm not sure.
> >
> > The diff is of the three files below vs the originals since I last
> updated
> > the source files.
> >
> > -Luke
> > --
> > -Luke
>
-- 
-Luke


I unveil()ed ftp(1)!

2020-06-03 Thread Luke Small
I think I'm done tinkering. try these out in ftp folder. I left in some
fprintf(ttyout,...) in main.c
to show what is being unveiled. It resolves shortcuts in SSL_CAFILE
and SSL_PATH variables.
It leaves in place the functionality of the original functions, but adds
the availability to perform
a dry run pass to load an unveil list of potential files from which to read
and create/write.
The only potential bug is perhaps if in the followup unveiled pass if it
has a problem with dns resolution or
something, it may be unveiled and drop into a command line. I'm not sure.

The diff is of the three files below vs the originals since I last updated
the source files.

-Luke
-- 
-Luke


diff
Description: Binary data
/*	$OpenBSD: main.c,v 1.131 2020/02/11 18:41:39 deraadt Exp $	*/
/*	$NetBSD: main.c,v 1.24 1997/08/18 10:20:26 lukem Exp $	*/

/*
 * Copyright (C) 1997 and 1998 WIDE Project.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the project nor the names of its contributors
 *may be used to endorse or promote products derived from this software
 *without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

/*
 * Copyright (c) 1985, 1989, 1993, 1994
 *	The Regents of the University of California.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the University nor the names of its contributors
 *may be used to endorse or promote products derived from this software
 *without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

/*
 * FTP User Program -- Command Interface.
 */
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include "cmds.h"
#include "ftp_var.h"

#ifndef SMALL
#include "pathnames.h"
#endif

int connect_timeout;

#ifndef NOSSL
char * const ssl_verify_opts[] = {
#define SSL_CAFILE		0
	"cafile",
#define SSL_CAPATH		1
	"capath",
#define SSL_CIPHERS		2
	"ciphers",
#define SSL_DONTVERIFY		3
	"dont",
#define SSL_DOVERIFY		4
	"do",
#define SSL_VERIFYDEPTH		5
	"depth",
#define SSL_MUSTSTAPLE		6
	"muststaple",
#define SSL_NOVERIFYTIME	7
	"noverifytime",
#define SSL_SESSION		8
	"session",
	NULL
};

struct tls_config *tls_config;
int tls_session_fd = -1;

static void
process_ssl_options(char *cp, char *ca_file, char *ca_path)
{
	const char *errstr;
	long long depth;
	char *str;

	while (*cp) {
		switch (getsubopt(, ssl_verify_opts, )) {
		case SSL_CAFILE:
			if (str == NULL)
errx(1, "missing CA file");
	

Re: Could somebody please put unveil() in ftp(1)?

2020-06-03 Thread Luke Small
I think I'm done tinkering. try these out in ftp folder. I left in some
fprintf(ttyout,...) in main.c
to show what is being unveiled. It resolves shortcuts in SSL_CAFILE
and SSL_PATH variables.
It leaves in place the functionality of the original functions, but adds
the availability to perform
a dry run pass to load an unveil list of potential files from which to read
and create/write.
The only potential bug is perhaps if in the followup unveiled pass if it
has a problem with dns resolution or
something, it may be unveiled and drop into a command line. I'm not sure.

The diff is of the three files below vs the originals since I last updated
the source files.

-Luke


On Tue, Jun 2, 2020 at 12:43 PM Kevin Chadwick  wrote:

> On 2020-06-02 17:28, Luke Small wrote:
> > I don’t have experience doing diffs. Are there flags I should be using
> in diff
> > or should I do diffs on each file? It’s just 3 files.
>
> I don't have that much experience myself, but if you look in tech@ you
> will see
> plenty of examples of cvs and git diffs for multiple files in one email
> inlined
> as text in the email itself.
>
> You may have to turn text wrapping off, etc. depending on your email
> client.
>


diff
Description: Binary data
/*	$OpenBSD: main.c,v 1.131 2020/02/11 18:41:39 deraadt Exp $	*/
/*	$NetBSD: main.c,v 1.24 1997/08/18 10:20:26 lukem Exp $	*/

/*
 * Copyright (C) 1997 and 1998 WIDE Project.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the project nor the names of its contributors
 *may be used to endorse or promote products derived from this software
 *without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

/*
 * Copyright (c) 1985, 1989, 1993, 1994
 *	The Regents of the University of California.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the University nor the names of its contributors
 *may be used to endorse or promote products derived from this software
 *without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

/*
 * FTP User Program -- Command Interface.
 */
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include "cmds.h"
#include "ftp_var.h"

#ifndef SMALL
#include "pathnames.h"
#endif

int connect_timeout;

#ifndef NOSSL
char * const ssl_verify_opts[] = {
#define SSL_CAFILE		0
	"cafile",
#defi

Re: Could somebody please put unveil() in ftp(1)?

2020-06-02 Thread Luke Small
I missed something.
-Luke


On Sat, May 30, 2020 at 2:53 PM Luke Small  wrote:

> I’ll get to looking at ftp(1) more when I get some physical contact with
> my server. I’m quaranteaming with my girlfriend’s folks.
>
> I have a pkg_ping program (OpenBSD-specific, dns caching, latency-timed,
> architecture and version specific mirror search; which doesn’t download
> from OpenBSD.org/ftp.html anymore) that calls ftp to look up a random
> mirror’s ftplist. and it seems unreasonable that with the availability of
> unveil, that ftp is hardly secured at all outside of a program that must be
> root and then change to an unprivileged user to have much of any real file
> system safety. The fact that ftp even has an interactive mode suggests to
> me that perhaps people do use, or at least, have used it as a normal user,
> seeing that if you put yourself in a chroot and try to run it, it will in
> most cases preclude your access to ftp(1) at all.
>
> I mentioned initially:
>
> It could take 3 lines at line 389 in /usr/src/usr.bin/ftp/main.c:
> if (strcmp(outfile, "-"))
> if (unveil(outfile, "cw") == -1)
>   err(1, "unveil");
>
> but it could look at several of the options like the cookie and
> certificate paths and such.
>
> I’d love to make it as safe to run as root as it is running it as an
> unprivileged chrooted user! And I love C!
>
> The reason I mentioned: “unveil(“/“, “rx”)“ is because if you unveiled
> anything like the “cw” privileges example, you’d obviously have to ensure
> that the read and exec privileges, perhaps even global ones are granted too.
>
> On Fri, May 29, 2020 at 8:50 AM Stuart Henderson 
> wrote:
>
>> On 2020/05/29 08:30, Luke Small wrote:
>> > You mention a lot of files that need to be read, but a program like
>> pkg_add can make it the
>> > _pkgfetch (57) user which has no directory and I’m guessing not in
>> interactive mode. At the
>> > very least, in noninteractive mode you could unveil(“/“, “rx”); and
>> change the specified output
>> > file discover the name of the file that is to be downloaded and unveil
>> it as “cw” !
>> > --
>> > -Luke
>>
>> What problem are you trying to solve?
>>
>> If you are concerned about writes, use "ftp -o - $URL > somefile", it will
>> run without cpath/wpath, which is functionally similar to unveil("/",
>> "rx")
>> (a bit stronger, because a program trying to write will be killed, rather
>> than just having a file access error).
>>
>> pkg_add(1) already uses "ftp -o -":
>>
>> # ktrace -di pkg_add -u moo
>> quirks-3.339 signed on 2020-05-27T20:05:28Z
>>
>> # kdump | grep promise=
>>  61644 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
>>  41938 signify  STRU  promise="stdio rpath wpath cpath tty"
>>  41938 signify  STRU  promise="stdio rpath"
>>  24897 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
>>  54324 signify  STRU  promise="stdio rpath wpath cpath tty"
>>  54324 signify  STRU  promise="stdio rpath"
>>   9188 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
>>
>> --
> -Luke
>


diff
Description: Binary data


Re: Could somebody please put unveil() in ftp(1)?

2020-05-30 Thread Luke Small
I’ll get to looking at ftp(1) more when I get some physical contact with my
server. I’m quaranteaming with my girlfriend’s folks.

I have a pkg_ping program (OpenBSD-specific, dns caching, latency-timed,
architecture and version specific mirror search; which doesn’t download
from OpenBSD.org/ftp.html anymore) that calls ftp to look up a random
mirror’s ftplist. and it seems unreasonable that with the availability of
unveil, that ftp is hardly secured at all outside of a program that must be
root and then change to an unprivileged user to have much of any real file
system safety. The fact that ftp even has an interactive mode suggests to
me that perhaps people do use, or at least, have used it as a normal user,
seeing that if you put yourself in a chroot and try to run it, it will in
most cases preclude your access to ftp(1) at all.

I mentioned initially:

It could take 3 lines at line 389 in /usr/src/usr.bin/ftp/main.c:
if (strcmp(outfile, "-"))
if (unveil(outfile, "cw") == -1)
  err(1, "unveil");

but it could look at several of the options like the cookie and certificate
paths and such.

I’d love to make it as safe to run as root as it is running it as an
unprivileged chrooted user! And I love C!

The reason I mentioned: “unveil(“/“, “rx”)“ is because if you unveiled
anything like the “cw” privileges example, you’d obviously have to ensure
that the read and exec privileges, perhaps even global ones are granted too.

On Fri, May 29, 2020 at 8:50 AM Stuart Henderson 
wrote:

> On 2020/05/29 08:30, Luke Small wrote:
> > You mention a lot of files that need to be read, but a program like
> pkg_add can make it the
> > _pkgfetch (57) user which has no directory and I’m guessing not in
> interactive mode. At the
> > very least, in noninteractive mode you could unveil(“/“, “rx”); and
> change the specified output
> > file discover the name of the file that is to be downloaded and unveil
> it as “cw” !
> > --
> > -Luke
>
> What problem are you trying to solve?
>
> If you are concerned about writes, use "ftp -o - $URL > somefile", it will
> run without cpath/wpath, which is functionally similar to unveil("/", "rx")
> (a bit stronger, because a program trying to write will be killed, rather
> than just having a file access error).
>
> pkg_add(1) already uses "ftp -o -":
>
> # ktrace -di pkg_add -u moo
> quirks-3.339 signed on 2020-05-27T20:05:28Z
>
> # kdump | grep promise=
>  61644 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
>  41938 signify  STRU  promise="stdio rpath wpath cpath tty"
>  41938 signify  STRU  promise="stdio rpath"
>  24897 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
>  54324 signify  STRU  promise="stdio rpath wpath cpath tty"
>  54324 signify  STRU  promise="stdio rpath"
>   9188 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
>
> --
-Luke


Re: Could somebody please put unveil() in ftp(1)?

2020-05-29 Thread Luke Small
You mention a lot of files that need to be read, but a program like pkg_add
can make it the _pkgfetch (57) user which has no directory and I’m guessing
not in interactive mode. At the very least, in noninteractive mode you
could unveil(“/“, “rx”); and change the specified output file discover the
name of the file that is to be downloaded and unveil it as “cw” !
-- 
-Luke


Could somebody please put unveil() in ftp(1)?

2020-05-28 Thread Luke Small
unveil is nowhere to be found in the ftp program source code. There’s
probably another way to do it, but I wrote a program and searched all files
in /usr/src/usr.bin/ftp/ contain no mention of “unveil”, but It mentions
“pledge”

It could take 3 lines at line 389 in /usr/src/usr.bin/ftp/main.c:
if (strcmp(outfile, "-"))
if (unveil(outfile, "cw") == -1)
  err(1, "unveil");

and an unveil for whatever (I presume config file(s)) ftp reads and
whatever is executed.

It has rpath and exec among other pledges, but has cpath and wpath only if
a file is specified with the ‘-o’ flag.
-- 
-Luke


Can root C program call to sysctl be pledge()ed?

2019-09-21 Thread Luke Small
I have need to call sysctl() in a C program to read
“sysctl kern.version”. Will there be a pledge() to prohibit further calls
to sysctl()? I’m kinda afraid that  putting a sysctl call could conceivably
leave it vulnerable to calling it again in the case the mitigations fail
and sysctl() is run to cause damage.

I want it to strstr() to find the existence of “beta” or “current” in
“sysctl kern.version”
-- 
-Luke


Re: 6.6-beta (RAMDISK_CD) #281 hangs on fsck

2019-09-08 Thread Luke Small
Yay!
-Luke


On Sun, Sep 8, 2019 at 8:07 PM David Gwynne  wrote:

> I think I see the problem. We're going to try and test this locally and
> will hopefully have something committed in a few hours time.
>
> dlg
>
> > On 9 Sep 2019, at 10:33, Luke Small  wrote:
> >
> > I have mfii too:
> > dmesg | grep mfii:
> >
> > mfii0 at pci11 dev 0 function 0 "Symbios Logic MegaRAID SAS2208" rev
> 0x05:
> > msi
> > mfii0: "LSI MegaRAID SAS 9271-8i", firmware 23.28.0-0010, 1024MB cache
> > scsibus1 at mfii0: 64 targets
> > scsibus2 at mfii0: 256 targets
> >
> >> On 8.9.2019. 18:19, Luke Small wrote:
> >>> It doesn't work for me on the
> >>> ftp.hostserver.de/archive/2019-08-29-0105/amd64/
> >>> bsd.rd!
> >>
> >>
> >> Hi,
> >>
> >> do you maybe have mfii on that box ?
> >>
> >> I'm having same problem as Mischa and i have mfii. with bsd.rd fsck
> >> stops with this command
> >>
> >> Which disk is the root disk? ('?' for details) [sd0] sd0
> >> Checking root filesystem (fsck -fp /dev/sd0a)...
> >>
> >> On other boxes without mfii bsd.rd and sysupgrade works just fine..
> >>
> >> between 27.08 and 29.8 i saw this commit
> >>
> >> Changes by:  d...@cvs.openbsd.org 2019/08/27 22:55:51
> >>
> >> Modified files:
> >>  sys/dev/pci: mfii.c
> >>
> >> Log message:
> >> implement a DV_POWERDOWN handler to flush cache and shutdown the
> controller
> >>
> >> this has been in snaps for the last week without issue, and has
> >> been running in production on a bunch of my boxes for a week before
> >> that, also without issue.
> >>
> >>
> >>
>
>


Re: 6.6-beta (RAMDISK_CD) #281 hangs on fsck

2019-09-08 Thread Luke Small
I have mfii too:
dmesg | grep mfii:

mfii0 at pci11 dev 0 function 0 "Symbios Logic MegaRAID SAS2208" rev 0x05:
msi
mfii0: "LSI MegaRAID SAS 9271-8i", firmware 23.28.0-0010, 1024MB cache
scsibus1 at mfii0: 64 targets
scsibus2 at mfii0: 256 targets

> On 8.9.2019. 18:19, Luke Small wrote:
> > It doesn't work for me on the
> > ftp.hostserver.de/archive/2019-08-29-0105/amd64/
> > bsd.rd!
>
>
> Hi,
>
> do you maybe have mfii on that box ?
>
> I'm having same problem as Mischa and i have mfii. with bsd.rd fsck
> stops with this command
>
> Which disk is the root disk? ('?' for details) [sd0] sd0
> Checking root filesystem (fsck -fp /dev/sd0a)...
>
> On other boxes without mfii bsd.rd and sysupgrade works just fine..
>
> between 27.08 and 29.8 i saw this commit
>
> Changes by:   d...@cvs.openbsd.org2019/08/27 22:55:51
>
> Modified files:
>   sys/dev/pci: mfii.c
>
> Log message:
> implement a DV_POWERDOWN handler to flush cache and shutdown the controller
>
> this has been in snaps for the last week without issue, and has
> been running in production on a bunch of my boxes for a week before
> that, also without issue.
>
>
>


Re: 6.6-beta (RAMDISK_CD) #281 hangs on fsck

2019-09-08 Thread Luke Small
Could it be? (from twitter):

“deraadt@ modified a couple things: At startup, unveil entire filesystem to
read-only. If after privdrop, some implausible bug existed in the socket
setup (mostly dns-related and setsockopt) it would be largely neutered. of
course, a very restrictive pledge is installed soon af...“

On Sun, Sep 8, 2019 at 11:19 AM Luke Small  wrote:

> It doesn’t work for me on the
> ftp.hostserver.de/archive/2019-08-29-0105/amd64/
> bsd.rd!
>
> On Sun, Sep 8, 2019 at 10:50 AM Luke Small  wrote:
>
>> Mine works on 8-27
>> --
>> -Luke
>>
> --
> -Luke
>
-- 
-Luke


Re: 6.6-beta (RAMDISK_CD) #281 hangs on fsck

2019-09-08 Thread Luke Small
It doesn’t work for me on the
ftp.hostserver.de/archive/2019-08-29-0105/amd64/
bsd.rd!

On Sun, Sep 8, 2019 at 10:50 AM Luke Small  wrote:

> Mine works on 8-27
> --
> -Luke
>
-- 
-Luke


Re: 6.6-beta (RAMDISK_CD) #281 hangs on fsck

2019-09-08 Thread Luke Small
Mine works on 8-27
-- 
-Luke


Re: Who has an ancient -current snapshot

2019-09-07 Thread Luke Small
Thanks, Somebody else directed me to it too! I got my server working
again!!!
-Luke


On Sat, Sep 7, 2019 at 3:52 AM Marcus MERIGHI  wrote:

> Hello Luke,
>
> lukensm...@gmail.com (Luke Small), 2019.09.07 (Sat) 00:56 (CEST):
> > I need an old kernel image older than maybe a couple weeks old. I have
> the
>
> I think http://ftp.hostserver.de/archive/ has what you want.
>
> Marcus
>


Who has an ancient -current snapshot

2019-09-06 Thread Luke Small
I need an old kernel image older than maybe a couple weeks old. I have the
x8dth-6f motherboard and newer snapshots broke it. I made the mistake of
trying to downgrade to 6.5 and now I can boot my machine! I made a
not-bright decision.
-- 
-Luke


Re: Can unveil pledge to only reduce?

2018-09-11 Thread Luke Small
I'm not sure that I wasn't ambiguous. I want to be able to set up all
necessary unveil promises then from that point on, be able to only reduce
unveil permissions. I don't know the mechanism by which is unveil works,
but perhaps it could be an unveil command similar to unveil(NULL, NULL)
instead of a pledge command? It apparently knows if it is an increase in
permissions, can't it be set to only permit them?

On Thu, Aug 16, 2018 at 2:00 PM Luke Small  wrote:

> Ok. Thanks.
> On Thu, Aug 16, 2018 at 1:59 PM Theo de Raadt  wrote:
>
>> Luke Small  wrote:
>> > Could you have a promise for unveil reductions only?
>>
>> That won't actually help much, and people will fall into some
>> pretty significant traps.
>>
>> Sorry it would require a really long explanation.
>>
>


Make new OpenBSD 2.5 daemon art!!!

2018-09-11 Thread Luke Small


Re: Can unveil pledge to only reduce?

2018-08-16 Thread Luke Small
Ok. Thanks.
On Thu, Aug 16, 2018 at 1:59 PM Theo de Raadt  wrote:

> Luke Small  wrote:
> > Could you have a promise for unveil reductions only?
>
> That won't actually help much, and people will fall into some
> pretty significant traps.
>
> Sorry it would require a really long explanation.
>


Can unveil pledge to only reduce?

2018-08-16 Thread Luke Small
Could you have a promise for unveil reductions only?


anybody installed angr, eg. pip install angr

2018-08-10 Thread Luke Small
It doesn't natively support OpenBSD.


This a good place to find a Sr. C coder 4 app server?

2018-07-24 Thread Luke Small
I have what I feel to be a profound idea that is in need of someone with a
strong resume. I have a patent. I want to use it to enable users to get
tested for sexually transmitted diseases, then use iris scanning
smartphones to compare their disease sets. There is a strong
epidemiological component that the US National Institutes of Health could
like. I am applying for grants. I have multiple HIV prevention scientists
willing to help me with this. At the end of he grants, I feel, is likely to
be strong possibility that we could use an existing mechanism to force the
health insurance companies to cover their customers for these services, and
cover it FOR FREE! The government doesn't consider costs when it makes this
decision. Also we could DOMINATE the dating app world by either making our
app that is free and contains the functionality of identifying other users
who won't transfer disease or plugging into tinder, match, and Grindr!
816-517-1996


Re: Can SSH report successful connections to pf?

2018-05-05 Thread Luke Small
Cool!
On Sat, May 5, 2018 at 3:17 AM Andreas Kusalananda Kähäri <
andreas.kah...@icm.uu.se> wrote:

> On Fri, May 04, 2018 at 11:56:33PM +, Kapfhammer, Stefan wrote:
> >
> > You might want to parse /var/log/authlog and the logrotated
> authlog.[0-9].gz
> > for successful and unsuccessful logins and then add the unsuccessful
> logins
> > with pfctl to a blocked table. To have it permanent after a reboot you
> can write
> > with pfctl the blocked ip's to a file, which you re-read in a pf.conf
> ruleset.
> >
> > Like
> > table  persist file "/etc/pf.bruteforce"
> > block in quick proto tcp from  to any
> >
> > Stefan
>
> This is *exactly* what sshguard does.  I have an updated
> security/sshguard port (previously posted to the ports list) that
> understands our sshd's log output, but it has not yet been comitted.
> There is currently some kind of issue with it preventing it from
> starting at boot (but always starts with "rcctl start sshguard").  I
> haven't looked too deeply at that yet though.
>
> Regards,
>
>
> --
> Andreas Kusalananda Kähäri,
> National Bioinformatics Infrastructure Sweden (NBIS),
> Uppsala University, Sweden.
>


Can SSH report successful connections to pf?

2018-05-04 Thread Luke Small
Can SSH and possibly other programs more easily able to report successful
connections so pf can make stricter bruteforce connection rejecting even
better?


Wouldn't it be cool...!

2018-04-06 Thread Luke Small
What if you could set up a pf rule to:

overload an ip address into a table if they tried to access the wrong port
on an address and overload flush global immediately into a blocklist

(

max-src-states
0)!

or with max-src-conn-rate 2/60 when sshd behaves in such a manner as to
confirm that a successful connection has taken place, that max-src-conn-rate
gets reset for that connection so that you could log in and log out faster
than twice in a minute without getting put on a blocklist!


Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Luke Small
I am not certain about Braille, but what I am sure of is there is no
incremental process to guessing a 64 bit datum that changes every single
execution. I typically don't state a fact unless I am willing to die if I
am incorrect. At least
https://en.m.wikipedia.org/wiki/Blind_return_oriented_programming seems to
state so. I dont fully trust wikipedia.
On Sat, Oct 14, 2017 at 3:06 AM Philip Guenther <guent...@gmail.com> wrote:

> On Sat, Oct 14, 2017 at 12:49 AM, Luke Small <lukensm...@gmail.com> wrote:
>
>> If that's true, then why has Theo been  speaking of the brop problems,
>> when they begin with an incremental canary discovery that becomes all but
>> impossible to guess when it becomes a random 4 byte datum each time rather
>> than a datum that remains the same each restart?
>>
>
> Because we are creatively optimistic pessimists: we can imagine
> possibilities for how other might be able to get around our defenses.
> Please watch review the presentation and read the source!
>
>
>
>> Braille should already be impossible to run on such a system, unless
>> maybe a restart was not the result of an exec.
>>
>
> The word "should" indicates that you are not certain.  How would you go
> about proving it?  What would you do if you couldn't?
>
> Philip Guenther
>
>


Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Luke Small
If that's true, then why has Theo been  speaking of the brop problems, when
they begin with an incremental canary discovery that becomes all but
impossible to guess when it becomes a random 4 byte datum each time rather
than a datum that remains the same each restart?

Braille should already be impossible to run on such a system, unless maybe
a restart was not the result of an exec.


Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Luke Small
I am not versed in operating systems as well as you, but I would think that
stack and buffer canaries would differ from each execution.


Re: Automatically restarting services/daemons after crash

2017-10-13 Thread Luke Small
Maybe more things should be randomized like the stack canaries. Is that a
new idea?
On Fri, Oct 13, 2017 at 11:34 PM Theo de Raadt  wrote:

> > I read "hacking blind." Can you restart a daemon with another forked
> > process that's only job is to monitor a pipe or a waitpid()-like
> operation
> > and if the parent dies, it exec's to restart it, or even execs "rcctl
> > restart ntpd"
> >
> > If the mitigations are successful at limiting execution to let's say,
> > overwriting a canary that gets completely rerandomized with a fork-exec,
> > instead of just a fork, it would stop a meaningful search for the correct
> > canary to just blind luck instead of byte by byte discovery.
>
> your position is very roughly: that paper lays out the absolute limit
> of what someone could learn from broken software, so as long as we run
> a new copy of the broken software we'll be safe
>
> obviously, no downside.
>
> you say "completely rerandomized" -- uhm no, only a tiny fraction of
> the program execution environment and runtime are randomized, in
> particular same registers used everywhere, same instruction sequences,
> same frame layouts, same register and stack leave-behinds, same
> relative offsets inside each DSO
>
> nothing learned from re-running buggy software?  sorry, that is BS.
>


Re: Automatically restarting services/daemons after crash

2017-10-13 Thread Luke Small
I read "hacking blind." Can you restart a daemon with another forked
process that's only job is to monitor a pipe or a waitpid()-like operation
and if the parent dies, it exec's to restart it, or even execs "rcctl
restart ntpd"

If the mitigations are successful at limiting execution to let's say,
overwriting a canary that gets completely rerandomized with a fork-exec,
instead of just a fork, it would stop a meaningful search for the correct
canary to just blind luck instead of byte by byte discovery.


pkg_add ignores -m

2017-10-09 Thread Luke Small
Using the -m flag it still gets warnings from pulseaudio and redis that I
didn't use the -m flag


Pledge paths[ ]

2017-06-14 Thread Luke Small
Is paths[] going to have permissions defined for each path?

Like:
char *paths[], int *mode, where mode is the same as in dbopen(3). Maybe so
you don't have to clean up previous pledge calls, any pledge calls with a
NULL paths argument doesn't have anything specified for mode. for
simplicity, modes could be only 2,4,5,6,7

So you could still do:
 pledge("stdio tmppath", NULL)

Then have:
char **temp_paths = calloc(2, sizeof(char*));
temp_paths[0] = malloc( strlen("/tmp/luke/file") + 1);
strlcpy(temp_paths[0], "/tmp/luke/file", sizeof(temp_paths[0]));

int *temp_modes = calloc(2, sizeof(int));
temp_modes[0] = 5;

pledge("stdio tmppath", temp_paths, temp_modes);
How about that?


How do you use EV_DISPATCH in kqueue(2)

2017-06-07 Thread Luke Small
Is EV_DISPATCH somehow like EV_ONESHOT or EVDISABLE ? What is a use case?

If you have an open socket file descriptor with a EVEFILT_READ, does it
close the socket upon getting some data?

I don't run current.


why does unbound listen as root

2017-05-12 Thread Luke Small
pf rule execution says it listens as root, but it connects as the _unbound
user, when configured to run as _unbound. Why doesn't it listen, bind, etc.
as root, drop privileges and pledge away privilege escalation? Is it to
avoid more #ifdef hell? Or can you not listen to a privileged port if you
drop privileges?


Re: list all system users, eg. _x11

2017-05-09 Thread Luke Small
Well, actually I like to play with firewall configurations and I set up
unbound and dnscrypt-proxy and I wanted to limit the users that are able to
receive dns requests on localhost port 53. I was trying to figure out what
user was listening. I haven't tried it yet, but I figure it is _dhcp and
_unbound. It didn't work when I limited it to _unbound alone. Maybe I
should have said that, but I wanted to generally know where the list was.

On Tue, May 9, 2017 at 1:57 PM andrew fabbro <and...@fabbro.org> wrote:

> Listing all users is trivial - I don't think that's what he's asking.
>
> He's asking is "how do I list all *system* users", presumably in a way
> that differentiates them from user accounts in some kind of authoritative
> way.
>
> I don't think there is a way.  You could:
>
> - Assume all users < uid 1000 are system users, but that is not hard
> enforced to my knowledge.  IIRC the OS will start with 1001 but an admin
> could override that at user creation time.
>
> - Use your preferred programming language or utility to parse out entries
> that begin with _ in /etc/passwd.  That won't get non-service-account
> entries like root, bin, etc.  Also, I don't think there's a technical
> prohibition to creating a new user account that starts with an underscore.
>
> - Differentiate by groups.  i.e., if all your users are in one group, then
> you know who isn't.
>
> I think if your admins don't do stupid things (create user accounts under
> 1000, create accounts starting with _, etc.) then just parsing /etc/passwd
> would likely be the simplest way.
>
> As practical experience, that's what I've done when migrating systems,
> etc.  I assume that people play by the rules, so if I need to identify all
> the user accounts (to recreate them on a new system or something), I
> exclude uids under 1000 as a starting point.
>
>
> On Mon, May 8, 2017 at 4:51 AM, Marcus MERIGHI <mcmer-open...@tor.at>
> wrote:
>
>> and...@msu.edu (STeve Andre'), 2017.05.06 (Sat) 20:37 (CEST):
>> > On 05/06/17 14:27, Luke Small wrote:
>> > > Is there a way to determine all users on a system that the users
>> command
>> > > doesn't seem to show? like _x11 and _ntpd
>>
>> users(1) - list current users
>>
>> I'd try ps(1) and get all active users from there.
>>
>> If you are after *all* users (inactive ones as well) you could use
>> "getent(1) passwd" and parse from there.
>>
>> Marcus
>>
>> > What's a user?
>> >
>> > Maybe you want to look at /etc/passwd.  The first four lines are
>> >
>> > root:*:0:0:Charlie &:/root:/bin/ksh
>> > daemon:*:1:1:The devil himself:/root:/sbin/nologin
>> > operator:*:2:5:System &:/operator:/sbin/nologin
>> > bin:*:3:7:Binaries Commands and Source:/:/sbin/nologin
>> >
>> > You can parse that with awk and do stuff.  Read about passwd(5) to
>> > understand the format.  A login shell of /sbin/nologin means
>> > it isn't interactive.  That might get you started?
>> >
>> > --STeve Andre'
>> >
>> >
>> > !DSPAM:590e28ea17913841584367!
>> >
>>
>>
>
>
> --
> andrew fabbro
> and...@fabbro.org
>
>


list all system users, eg. _x11

2017-05-06 Thread Luke Small
Is there a way to determine all users on a system that the users command
doesn't seem to show? like _x11 and _ntpd


Pf with secondary DNS resolution

2017-05-03 Thread Luke Small
Four words Peter..."dynamic IP address". I'm sure that there are folks that
ssh into machines that are on a dynamic IP address that don't have a modem
on a power backup, or even possibly on an ISP that may down, possibly when
they are out of town. I don't know if it is possible or already done, but
you could have a computer check into a target machine that often changes
the ip address or system while the firewall is locked down to only send
messages to that remote machine and if it is compromised, can't send it
anywhere else. Or you ssh into the machine and it only accepts incoming
port 22 requests from a machine that has a dynamic url and listed in your
pf.conf. maybe you could even signify in the pf.conf that the url will
often have a different ip address and it could request that ip address
every time it gets a hit on that rule or a maximum upperbound.


Re: Pf with secondary DNS resolution

2017-05-03 Thread Luke Small
Four words Peter..."dynamic IP address". I'm sure that there are folks that
ssh into machines that are on a dynamic IP address that don't have a modem
on a power backup, or even possibly on an ISP that may down, possibly when
they are out of town. I don't know if it is possible or already done, but
you could have a computer check into a target machine that often changes
the ip address or system while the firewall is locked down to only send
messages to that remote machine and if it is compromised, can't send it
anywhere else.

On Wed, May 3, 2017 at 3:16 PM Luke Small <lukensm...@gmail.com> wrote:

> Is it worthwhile to set up a hook for pf to load rules that have URLs
> after the network services that can resolve them come into effect?


Pf with secondary DNS resolution

2017-05-03 Thread Luke Small
Is it worthwhile to set up a hook for pf to load rules that have URLs after
the network services that can resolve them come into effect?


80 users

2017-04-29 Thread Luke Small
As I recall, there is a build configuration of 80 users for some kernel
components. What happens if the system exceeds that number?


Re: pledge for sockets

2017-04-29 Thread Luke Small
I think I found a way to configure the redis.conf to connect to redis
through a unix socket instead, which will seem to clean up some stuff. If I
need to later, I could probably spawn a process to relay commands from a
unix socket to an inet socket that is limited to a single port through a
different user through pf (and when I get a more serious machine, possibly
through a unique interface). Most importantly, I need it for session cache
for multiple processes.
On Sat, Apr 29, 2017 at 10:02 AM Luke Small <lukensm...@gmail.com> wrote:

> I have a program that I believe needs inet to talk to a
> database(libhiredis). I do pass file descriptors to it. I don't suppose
> making it run as a different user and limiting the pf config would really
> lock it down without losing functionality. Maybe I'm too paranoid.
> On Sat, Apr 29, 2017 at 9:51 AM Reyk Floeter <r...@openbsd.org> wrote:
>
>>
>> > Am 26.04.2017 um 13:38 schrieb Luke Small <lukensm...@gmail.com>:
>> >
>> > Pledge will presumably have per process (including fork()ed process)
>> **path
>> > limitations on rpath rpath and wpath calls, why not limitations on inet
>> and
>> > unix?
>>
>> We usually want to isolate our network speakers from the local system -
>> combining inet and rpath/wpath should be avoided.
>>
>> Use privsep and fd passing to open the socket in another process with the
>> capability to do so.
>>
>> This is what we do in most daemons.
>>
>> Or open the socket before pledge for static configurations.
>>
>> Reyk
>>
>> >> On Wed, Apr 26, 2017 at 6:26 AM Janne Johansson <icepic...@gmail.com>
>> wrote:
>> >>
>> >> 2017-04-26 13:19 GMT+02:00 Luke Small <lukensm...@gmail.com>:
>> >>
>> >>> I'm not saying to alter pledge necessarily, maybe make new system call
>> >>> like pledge. There aren't any per-process pf rules that are applied.
>> >>
>> >>
>> >> If your daemon has a specific user, you can make such rules in PF.
>> >> The goal you stated can be reached already, why keep on suggesting new
>> >> syscalls?
>> >>
>> >>
>> >> --
>> >> May the most significant bit of your life be positive.
>> >>
>>
>>


Re: pledge for sockets

2017-04-29 Thread Luke Small
I have a program that I believe needs inet to talk to a
database(libhiredis). I do pass file descriptors to it. I don't suppose
making it run as a different user and limiting the pf config would really
lock it down without losing functionality. Maybe I'm too paranoid.
On Sat, Apr 29, 2017 at 9:51 AM Reyk Floeter <r...@openbsd.org> wrote:

>
> > Am 26.04.2017 um 13:38 schrieb Luke Small <lukensm...@gmail.com>:
> >
> > Pledge will presumably have per process (including fork()ed process)
> **path
> > limitations on rpath rpath and wpath calls, why not limitations on inet
> and
> > unix?
>
> We usually want to isolate our network speakers from the local system -
> combining inet and rpath/wpath should be avoided.
>
> Use privsep and fd passing to open the socket in another process with the
> capability to do so.
>
> This is what we do in most daemons.
>
> Or open the socket before pledge for static configurations.
>
> Reyk
>
> >> On Wed, Apr 26, 2017 at 6:26 AM Janne Johansson <icepic...@gmail.com>
> wrote:
> >>
> >> 2017-04-26 13:19 GMT+02:00 Luke Small <lukensm...@gmail.com>:
> >>
> >>> I'm not saying to alter pledge necessarily, maybe make new system call
> >>> like pledge. There aren't any per-process pf rules that are applied.
> >>
> >>
> >> If your daemon has a specific user, you can make such rules in PF.
> >> The goal you stated can be reached already, why keep on suggesting new
> >> syscalls?
> >>
> >>
> >> --
> >> May the most significant bit of your life be positive.
> >>
>
>


Re: pledge for sockets

2017-04-26 Thread Luke Small
Pledge will presumably have per process (including fork()ed process) **path
limitations on rpath rpath and wpath calls, why not limitations on inet and
unix?
On Wed, Apr 26, 2017 at 6:26 AM Janne Johansson <icepic...@gmail.com> wrote:

> 2017-04-26 13:19 GMT+02:00 Luke Small <lukensm...@gmail.com>:
>
>> I'm not saying to alter pledge necessarily, maybe make new system call
>> like pledge. There aren't any per-process pf rules that are applied.
>
>
> If your daemon has a specific user, you can make such rules in PF.
> The goal you stated can be reached already, why keep on suggesting new
> syscalls?
>
>
> --
> May the most significant bit of your life be positive.
>


Re: pledge for sockets

2017-04-26 Thread Luke Small
I'm not saying to alter pledge necessarily, maybe make new system call
like pledge. There aren't any per-process pf rules that are applied.
When a socket connects to a remote or local server and pf makes a
state, it has the originating randomized port. Pf rules can be made
that target those randomized port numbers, but maybe there could be a
more elegant way like intervening in connect() and bind() calls.

>you can have rules to filter by user >for both
>incoming and outgoing connections, see
>http://man=2Eopenbsd=2Eorg/OpenBSD->6=2E1/pf=2Econf=2E5#user

>I don't think there's too much gain in >adding
>support for this kinda thing in pledge >but
>that's for the devs to decide=2E=20


pledge for sockets?

2017-04-26 Thread Luke Small
Would it be a good idea to make a pledge like call that limits a process
from connecting to ports and/or hosts? Maybe it could be done in way that
the kernel is made aware of the limitations like in a pledge call and while
the process is alive, the kernel spawns pf rules based upon the socket
ports that are created to connect to remote host ports.

You could conceivably do things like limiting ntpd to predetermined hosts
and port 123 and 53 on the respective processes involved.

It would make processes that need the inet pledge permission merely to use
libhiredis to connect to a Redis database more safe.


Re: kqueue

2017-04-19 Thread Luke Small
It looks like you will be limited to 4096 timers and to valid file
descriptors that don't exceed INT_MAX. My guess is that if you need more,
you could run another kqueue for more timers or different kevents on
identical file descriptors.

Otherwise, the man page says:
kevent() returns the number of events placed in the eventlist, up to the
 value given by nevents.  If an error occurs while processing an element
 of the changelist and there is enough room in the eventlist, then the
 event will be placed in the eventlist with EV_ERROR set in flags and
the
 system error in data.  Otherwise, -1 will be returned, and errno will
be
 set to indicate the error condition.


kqueue

2017-04-18 Thread Luke Small
I suspect that you will sooner run out of file descriptors. but I assume
that if it runs into a problem, kevent() will return  -1 and it may be
unrecoverable. I suspect that it would first occur because the kernel is
being overutilized. The information that is being created, I suspect, is
being stored in the kernel. I may look into the source code and try to find
out. You'd probably have to edit /etc/login.conf as root to allow enough
file descriptors to be spawned in the first place. But maybe you could do
it with EVFILT_TIMER calls, as they don't require a file descriptor as an
'ident'. I suspect that the whole kqueue is flushed if you exceed a
specific level.


Re: Why isn't OpenBSD in Google Summer of Code 2017?...

2017-04-05 Thread Luke Small
I suspect that unless you really know what you are doing, you'll never
satisfy
the OpenBSD gods. I suspect that there is a good reason that pkg_add was
rewritten in perl. I suspect because it may have been written in perl. And
just like that a
good idea wasn't completely done in another way.

On Wed, Apr 5, 2017 at 9:55 AM Jacob L. Leifman <jac...@bitwise.net> wrote:

> Security and correctness should never be an after-thought. Have you
> done any real software development? And have you ever tried to find
> your way through cruddy code? 999 times out of 1000 it is less painful
> and much more effective to rewrite from scratch. So what's the point of
> having that previous iteration?
>
> On 5 Apr 2017 at 13:10, Luke Small wrote:
>
> > I imagine there are some projects that need some love that are on the
> back
> > burner at the moment that could use some hacking; even if it is totally
> > redone later by someone that wants to refactor it for privsep and such.
> > On Tue, Apr 4, 2017 at 4:21 PM Theo de Raadt <dera...@openbsd.org>
> wrote:
> >
> > > Pete, you propose a waste of time.
> > >
> > > Everyone has the source code.  Everyone can run it.  Everyone can see
> > > the problems other people report, and the things which are not
> supported.
> > >
> > > Everyone already can tell what needs improving.  Everyone has a brain,
> > > and can come up with their own goals.
> > >
> > > If they don't come up with goals, there's nothing we can write which
> > > will change anything.
> > >
> > > Finally, not everyone has time.  It would not be time spent well making
> > > lists for other people who may or may not perform.
> > >
> > > > Would the devs consider compiling a list of specific improvements
> they'd
> > > like
> > > > to see volunteer'd upon this summer? I'd love to help especially if
> it
> > > was a
> > > > group effort/friendly competition.
> > > >
> > > > 
> > > > From: owner-m...@openbsd.org <owner-m...@openbsd.org> on behalf of
> Bob
> > > Beck
> > > > <b...@obtuse.com>
> > > > Sent: April 2, 2017 10:16:21 PM
> > > > To: Luke Small
> > > > Cc: openbsd-misc
> > > > Subject: Re: Why isn't OpenBSD in Google Summer of Code 2017?...
> > > >
> > > > We tried it for two years, it was too much effort on the part of the
> > > > foundation organizers mentors to deal with the bureaucracy involved,
> and
> > > we
> > > > didn't really see enough
> > > > return in terms of new developers to the project, which, frankly
> being
> > > > selfish on OpenBSD's part is the only reason for us to do it.
> > > >
> > > > Both Ken Westerback and I organized our end of it and dealt with the
> > > google
> > > > paperwork the two years we did it, Neither of us is willing to do it
> > > again,
> > > > and while I won't
> > > > directly speak for Ken, I would not support us spending effort on
> this
> > > when
> > > > there are lots of other things to do.. It just doesn't have the
> benefit
> > > for
> > > > OpenBSD, especially
> > > > in light of the effort of the volunteers necessary to participate.
> > > >
> > > >
> > > >
> > > > On Sun, Apr 2, 2017 at 8:54 AM, Luke Small <lukensm...@gmail.com>
> wrote:



Re: Why isn't OpenBSD in Google Summer of Code 2017?...

2017-04-05 Thread Luke Small
Bring on the Flaming Theo!

On Wed, Apr 5, 2017 at 3:55 PM Flipchan <flipc...@riseup.net> wrote:

> Ping Theo, couldnt someone create a needs improvments list n put it on
> like OpenBSD.org?
>
> Luke Small <lukensm...@gmail.com> skrev: (2 april 2017 16:54:39 CEST)
>
>
> --
> Sincerly flipchan - LayerProx dev



Re: Why isn't OpenBSD in Google Summer of Code 2017?...

2017-04-05 Thread Luke Small
I imagine there are some projects that need some love that are on the back
burner at the moment that could use some hacking; even if it is totally
redone later by someone that wants to refactor it for privsep and such.
On Tue, Apr 4, 2017 at 4:21 PM Theo de Raadt <dera...@openbsd.org> wrote:

> Pete, you propose a waste of time.
>
> Everyone has the source code.  Everyone can run it.  Everyone can see
> the problems other people report, and the things which are not supported.
>
> Everyone already can tell what needs improving.  Everyone has a brain,
> and can come up with their own goals.
>
> If they don't come up with goals, there's nothing we can write which
> will change anything.
>
> Finally, not everyone has time.  It would not be time spent well making
> lists for other people who may or may not perform.
>
> > Would the devs consider compiling a list of specific improvements they'd
> like
> > to see volunteer'd upon this summer? I'd love to help especially if it
> was a
> > group effort/friendly competition.
> >
> > 
> > From: owner-m...@openbsd.org <owner-m...@openbsd.org> on behalf of Bob
> Beck
> > <b...@obtuse.com>
> > Sent: April 2, 2017 10:16:21 PM
> > To: Luke Small
> > Cc: openbsd-misc
> > Subject: Re: Why isn't OpenBSD in Google Summer of Code 2017?...
> >
> > We tried it for two years, it was too much effort on the part of the
> > foundation organizers mentors to deal with the bureaucracy involved, and
> we
> > didn't really see enough
> > return in terms of new developers to the project, which, frankly being
> > selfish on OpenBSD's part is the only reason for us to do it.
> >
> > Both Ken Westerback and I organized our end of it and dealt with the
> google
> > paperwork the two years we did it, Neither of us is willing to do it
> again,
> > and while I won't
> > directly speak for Ken, I would not support us spending effort on this
> when
> > there are lots of other things to do.. It just doesn't have the benefit
> for
> > OpenBSD, especially
> > in light of the effort of the volunteers necessary to participate.
> >
> >
> >
> > On Sun, Apr 2, 2017 at 8:54 AM, Luke Small <lukensm...@gmail.com> wrote:



I can't connect to openbsd.org in most cases.

2017-04-04 Thread Luke Small
I have an openbsd vm on a windows 7 host, windows 7 asus, iPhone, and
Android phone. Only the iPhone 7+ seems to be able to connect to openbsd.org
correctly without getting a https validation error. they are all going
through the same wifi router.

I am running firefox on everything. Safari also worked on iPhone.



Re: Why isn't OpenBSD in Google Summer of Code 2017?...

2017-04-02 Thread Luke Small
I wonder if pledge has been fully implemented to include paths?
On Mon, Apr 3, 2017 at 12:34 AM Pete Zabagel <pete.zaba...@outlook.com>
wrote:

> Would the devs consider compiling a list of specific improvements they'd
> like to see volunteer'd upon this summer? I'd love to help especially if it
> was a group effort/friendly competition.
>
> 
> From: owner-m...@openbsd.org <owner-m...@openbsd.org> on behalf of Bob
> Beck <b...@obtuse.com>
> Sent: April 2, 2017 10:16:21 PM
> To: Luke Small
> Cc: openbsd-misc
> Subject: Re: Why isn't OpenBSD in Google Summer of Code 2017?...
>
> We tried it for two years, it was too much effort on the part of the
> foundation organizers mentors to deal with the bureaucracy involved, and we
> didn't really see enough
> return in terms of new developers to the project, which, frankly being
> selfish on OpenBSD's part is the only reason for us to do it.
>
> Both Ken Westerback and I organized our end of it and dealt with the google
> paperwork the two years we did it, Neither of us is willing to do it again,
> and while I won't
> directly speak for Ken, I would not support us spending effort on this when
> there are lots of other things to do.. It just doesn't have the benefit for
> OpenBSD, especially
> in light of the effort of the volunteers necessary to participate.
>
>
>
> On Sun, Apr 2, 2017 at 8:54 AM, Luke Small <lukensm...@gmail.com> wrote:



Re: Topics for revised PF and networking tutorial

2017-04-02 Thread Luke Small
It might be a fun idea to share what a really locked down desktop system
pf.conf would look like like if you are running a chain of DNS services (or
something that would be good to tightly control) like local ntpd, unbound,
and dnscrypt_proxy where you have local traffic locked down as well so that
an aberrant process or even root cannot connect to the local ports and
services eg.

pass out quick on lo0 proto {tcp, udp} from self to any port 53 user
{peter, _ntpd}

block out log quick on lo0 proto {tcp, udp} from self to any port 53


pass in quick on lo0 proto {tcp, udp} from any to self port 53 user _unbound

block in log quick on lo0 proto {tcp, udp} from any to self port 53



pass out quick on lo0 proto {tcp, udp} from self to any port 40 user
_unbound

block out log quick on lo0 proto {tcp, udp} from self to any port 40


pass in quick on lo0 proto {tcp, udp} from any to self port 40 user
_dnscrypt_proxy

block in log quick on lo0 proto {tcp, udp} from any to self port 40


pass out quick on egress proto {tcp, udp} from self to any port 53  user
_dnscrypt_proxy

block out log quick on egress proto {tcp, udp} from self to any port 53

Maybe there is a similar case that can be made, possibly with a reverse
http proxy setup that would make more sense for security in the case that a
vulnerability is discovered.



Why isn't OpenBSD in Google Summer of Code 2017?...

2017-04-02 Thread Luke Small


Is there something to replace zaurus?

2017-03-29 Thread Luke Small
I thought I read that there is an arm7 based mobile device, but I can't
find anything about it.



Re: For the super paranoid

2017-03-11 Thread Luke Small
At least you can protect yourself from corporate espionage; unless it's
intel
On Sat, Mar 11, 2017 at 1:36 PM <biggran...@tds.net> wrote:

> https://en.wikipedia.org/wiki/TRESOR
>
> A Linux kernel patch which provides CPU-only based encryption
> <https://en.wikipedia.org/wiki/Encryption> to defend against cold boot
> attacks <https://en.wikipedia.org/wiki/Cold_boot_attack> on computer
> systems by performing encryption outside usual random-access memory
> <https://en.wikipedia.org/wiki/Random-access_memory> (RAM
>
>
> https://software.intel.com/en-us/blogs/2016/02/26/memory-encryption-an-intel-sgx-underpinning-technology
>
> The Intel SGX Memory Encryption Engine:
>
>
> You just have to ask yourself, Intel, who has the keys to the Intel ME...
> Paranoia^2
> There is no perfect security, especially when one can touch the hardware.
>
>
>
>
> On 3/11/2017 11:44 AM, Luke Small wrote:
>
> Is there a way to encrypt memory and keep the key on the CPU like a
> transparent partition so that if the ram cards are physically accessed, hey
> can't be read? Is it reasonable?



For the super paranoid

2017-03-11 Thread Luke Small
Is there a way to encrypt memory and keep the key on the CPU like a
transparent partition so that if the ram cards are physically accessed, hey
can't be read? Is it reasonable?



make pf allow out on lo per user

2017-01-24 Thread Luke Small
if I have:
"pass out quick on lo0 from self port 6379 to \ any user luke

block out quick on lo0 from self port 6379 to any

pass quick on lo0 from any to any"

a local connection to port 6379 will go to the last rule... isn't this a
useful feature to allow one of the first two rules to take effect?



Re: Pf on lo0

2017-01-18 Thread Luke Small
e Creations: 0 ]
@13 block drop out quick on lo0 inet proto tcp from 127.0.0.1 port = 6379
to any label "Rule 1d"
  [ Evaluations: 0 Packets: 0 Bytes: 0   States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@14 block drop out quick on lo0 inet proto tcp from 10.0.2.15 port = 6379
to any label "Rule 1d"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@15 block drop out quick on lo0 inet proto udp from 127.0.0.1 port = 6379
to any label "Rule 1d"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@16 block drop out quick on lo0 inet proto udp from 10.0.2.15 port = 6379
to any label "Rule 1d"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@17 pass in quick on lo0 inet proto tcp from any to 127.0.0.1 port = 6380
user = 1002 flags S/SA label "Rule 1e"
  [ Evaluations: 26Packets: 519   Bytes: 31009   States:
9 ]
  [ Inserted: uid 0 pid 89214 State Creations: 9 ]
@18 pass in quick on lo0 inet proto tcp from any to 10.0.2.15 port = 6380
user = 1002 flags S/SA label "Rule 1e"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@19 block drop in quick on lo0 inet proto tcp from any to 127.0.0.1 port =
6380 label "Rule 1f"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@20 block drop in quick on lo0 inet proto tcp from any to 10.0.2.15 port =
6380 label "Rule 1f"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@21 block drop in quick on lo0 inet proto udp from any to 127.0.0.1 port =
6380 label "Rule 1f"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@22 block drop in quick on lo0 inet proto udp from any to 10.0.2.15 port =
6380 label "Rule 1f"
  [ Evaluations: 0 Packets: 0 Bytes: 0   States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@23 pass out quick on lo0 inet proto tcp from 127.0.0.1 port = 6380 to any
user = 1000 flags S/SA label "Rule 1g"
  [ Evaluations: 17Packets: 0 Bytes: 0   States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@24 pass out quick on lo0 inet proto tcp from 10.0.2.15 port = 6380 to any
user = 1000 flags S/SA label "Rule 1g"
  [ Evaluations: 0 Packets: 0 Bytes: 0   States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@25 block drop out quick on lo0 inet proto tcp from 127.0.0.1 port = 6380
to any label "Rule 1h"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@26 block drop out quick on lo0 inet proto tcp from 10.0.2.15 port = 6380
to any label "Rule 1h"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@27 block drop out quick on lo0 inet proto udp from 127.0.0.1 port = 6380
to any label "Rule 1h"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@28 block drop out quick on lo0 inet proto udp from 10.0.2.15 port = 6380
to any label "Rule 1h"
  [ Evaluations: 0 Packets: 0 Bytes: 0States: 0 ]
  [ Inserted: uid 0 pid 89214 State Creations: 0 ]
@29 pass quick on lo0 inet all flags S/SA label "RULE 1 -- ACCEPT "
  [ Evaluations: 17   Packets: 547  Bytes: 32680   States: 17]
  [ Inserted: uid 0 pid 89214 State Creations: 17]
...

On Tue, Jan 17, 2017 at 2:00 AM Luke Small <lukensm...@gmail.com> wrote:

> It doesn't. The "pass in quick on lo0 proto {tcp,udp}from any port 6379 to
> self port 6379 user luke" works.
>
> On Mon, Jan 16, 2017, 23:48 Sebastien Marie <sema...@online.fr> wrote:
>
> On Mon, Jan 16, 2017 at 11:04:48PM +, Luke Small wrote:
> > I'm trying to have pf limit sending TCP packets over lo0 from a specific
> > user. I made some rules, but they seem to be ignored when I check on
> pfctl
> > -vvvs rules it goes to the default lo0 pass rule: "pass out quick on lo0
> > proto { tcp, udp } from self port 6379 to any port 6379 user luke" and
> > "block out quick on lo0 proto {tcp,udp} from self to any port 6379"
> > obviously I'm using redis. Redis has authentication, but I think it'd be
> > cool to have that extra layer of protection.
> >
>
> check your /etc/pf.conf if it contains a line like:
>
> set skip on lo
>
> (it is in default pf.conf file), and remove it.
>
> pf(4) will not skip lo group, so lo0 will be filtered.
> --
> Sebastien Marie



Re: Pf on lo0

2017-01-17 Thread Luke Small
It doesn't. The "pass in quick on lo0 proto {tcp,udp}from any port 6379 to
self port 6379 user luke" works.

On Mon, Jan 16, 2017, 23:48 Sebastien Marie <sema...@online.fr> wrote:

> On Mon, Jan 16, 2017 at 11:04:48PM +, Luke Small wrote:
> > I'm trying to have pf limit sending TCP packets over lo0 from a specific
> > user. I made some rules, but they seem to be ignored when I check on
> pfctl
> > -vvvs rules it goes to the default lo0 pass rule: "pass out quick on lo0
> > proto { tcp, udp } from self port 6379 to any port 6379 user luke" and
> > "block out quick on lo0 proto {tcp,udp} from self to any port 6379"
> > obviously I'm using redis. Redis has authentication, but I think it'd be
> > cool to have that extra layer of protection.
> >
>
> check your /etc/pf.conf if it contains a line like:
>
> set skip on lo
>
> (it is in default pf.conf file), and remove it.
>
> pf(4) will not skip lo group, so lo0 will be filtered.
> --
> Sebastien Marie



Pf on lo0

2017-01-16 Thread Luke Small
I'm trying to have pf limit sending TCP packets over lo0 from a specific
user. I made some rules, but they seem to be ignored when I check on pfctl
-vvvs rules it goes to the default lo0 pass rule: "pass out quick on lo0
proto { tcp, udp } from self port 6379 to any port 6379 user luke" and
"block out quick on lo0 proto {tcp,udp} from self to any port 6379"
obviously I'm using redis. Redis has authentication, but I think it'd be
cool to have that extra layer of protection.



Re: Why can I waitpid() but can't EVFILT_PROC under pledge("proc")

2017-01-05 Thread Luke Small
You could possibly make a separate "event" or "wait" pledge to register new
events or NOTE_EXIT calls, but I suspect that that would complicate things,
making the large presumption that that could be desired.

On Thu, Jan 5, 2017, 15:42 Theo de Raadt  wrote:

> > I imagine that the mitigation that is sought by pledge is to minimize
> > aberrent code reuse in whatever way a hacker can make code run again in a
> > way that it isn't supposed to. And maybe the programmer can choose what
> can
> > be problematic and what isn't if it runs again with their choice of the
> > calls. What problem could occur that EVFILT_PROC with NOTE_EXIT (as
> opposed
> > to EVFILT_PROC with maybe other fflags) could make that couldn't occur by
> > trying to put a kevent on a file descriptor. Is "abusively" monitoring a
> > process a security hole?
>
> You want to avoid using pledge "proc" in your own code; you want
> EVFILT_PROC to just work.  I guess you wish that EVFILT_PROC was
> always enabled, inside the pledge "stdio" environment, since you
> haven't described another proposal for what would toggle access.
>
> But that means you don't care about everyone else's code, in
> particular the whole base system.  1000+ code-chunks in the tree use
> "stdio" (or something else slightly more) for normal operation, but
> don't need or want EVFILT_PROC access as a matter of course.
>
> So you think those 1000+ code-chunks should gain EVFILT_PROC ability,
> because it is convenient for your code.  Result is if any of those
> code-chunks has a buffer overflow or means for code execution
> achievement, then it can observe all processes in the system.
>
> Basically, you desire that all pledge "stdio" processes can scan for
> the existance of all pid's by doing EVFILT_PROC attempts.  YES, that
> is exactly what you want, I am not mincing words!  Basically you want
> to undo the annotation/safety of pledge, because you haven't thought
> things through.
>
> Like, you'd be OK if a bug in the sshd pre-auth sandbox allowed such an
> operation?
>
> > If it is, shouldn't a task manager be run as root to see when a root
> > process dies?
>
> That has nothing to do with pledge.  If you want to ask an entirely
> seperate question, ask it in a seperate email.



Re: Why can I waitpid() but can't EVFILT_PROC under pledge("proc")

2017-01-05 Thread Luke Small
Registering a EVFILT_PROC, NOTE_EXIT kevent requires proc

On Thu, Jan 5, 2017, 15:25 Ted Unangst <t...@tedunangst.com> wrote:

> Theo de Raadt wrote:
> > > Luke Small wrote:
> > > > What if I want to prevent a process from forking while I want to
> create new
> > > > EVFILT_PROC events? Say, to accept the pid of a sibling fork from a
> pipe
> > > > and load it into a kqueue. Is there a reason why waitpid() isn't
> beholden
> > > > to this, or is there a reason that EVFILT_PROC is?
> > >
> > > wait() is a less powerful syscall than kevent().
> >
> > indeed, EVFILT_PROC lets you observe processes other than your own
> > children.
> >
> > that way far outside "stdio", you are reasoning about processes in
> general,
> > so of course you need pledge "proc".
>
> I should also clarify a bit. wait() only works for processes you've created
> with fork(), which requires "proc". There's good reason to allow you to
> watch
> for a child's exit much later, but without the ability to fork again.
>
> Also, kevent allows exactly this setup with the same set of pledges. After
> calling fork() is when you attach the kevent for the child. Then you drop
> "proc" and can continue to receive notifications about child exits.
>
> Using kevent() in the same way as wait() requires exactly the same pledge.



Re: Why can I waitpid() but can't EVFILT_PROC under pledge("proc")

2017-01-05 Thread Luke Small
I imagine that the mitigation that is sought by pledge is to minimize
aberrent code reuse in whatever way a hacker can make code run again in a
way that it isn't supposed to. And maybe the programmer can choose what can
be problematic and what isn't if it runs again with their choice of the
calls. What problem could occur that EVFILT_PROC with NOTE_EXIT (as opposed
to EVFILT_PROC with maybe other fflags) could make that couldn't occur by
trying to put a kevent on a file descriptor. Is "abusively" monitoring a
process a security hole? If it is, shouldn't a task manager be run as root
to see when a root process dies? It would be difficult enough to discover a
pid when you aren't supposed to since they probably wouldn't be stored
unless they are going to be used. waitpid(pid, , WNOHANG); in a loop
could do the same thing as that, but would be uglier to implement. I
suppose it may be difficult to turn back now after pledging so much in a
certain way.

On Thu, Jan 5, 2017, 14:41 Ted Unangst <t...@tedunangst.com> wrote:

Luke Small wrote:
> What if I want to prevent a process from forking while I want to create
new
> EVFILT_PROC events? Say, to accept the pid of a sibling fork from a pipe
> and load it into a kqueue. Is there a reason why waitpid() isn't beholden
> to this, or is there a reason that EVFILT_PROC is?

wait() is a less powerful syscall than kevent().



Why can I waitpid() but can't EVFILT_PROC under pledge("proc")

2017-01-05 Thread Luke Small
What if I want to prevent a process from forking while I want to create new
EVFILT_PROC events? Say, to accept the pid of a sibling fork from a pipe
and load it into a kqueue. Is there a reason why waitpid() isn't beholden
to this, or is there a reason that EVFILT_PROC is?



fresh install to i386 kde4 only has UTC on clock...

2016-10-08 Thread Luke Small


odd microsoft mouse mappings

2016-10-08 Thread Luke Small
Can I change usbhidctrl to change how it is mapped. the middle scroll moves
the mouse up. the left-right movement on the mouse works, but the up and
down seems to right click. I don't know what the rest does.



Re: might it be better to have three paths lists

2016-09-03 Thread Luke Small
If a program requires studio, wpath, rpath, dns, and inet. It spawns
multiple threads. The socket binding thread is taken over, runs arbitrary
code that overflows a buffer of the thread listening to a pipe with rpath
and stdio permissions it reads the binary of an executable the company
wants to remain private, but is on the paths list, which gives the process
unintentional read permissions and sends it to the attacker.
Because we know everybody writes perfect code. With finer grained paths
permissions, it is possible to gain even better control amidst really well
pledged and privilege separated programs(even if they are imperfectly
bounded), it may be possible to have a slightly more complicated paths
setup with less privilege separation, written by programmers that spend a
bit less time with privilege separation, to meet deadlines and achieve
comparable results.

On Sat, Sep 3, 2016, 04:41 ludovic coues <cou...@gmail.com> wrote:

> 2016-09-03 11:04 GMT+02:00 Luke Small <lukensm...@gmail.com>:
> >
> >
> > Sorry  I was in the middle of something, but pledge can be a broad brush,
> > unless you are dealing with one file, whether it is executed, read, or
> > written and giving per process file permissions sounds pretty neat, and
> it
> > might just be a little simpler than making new users for each subset of
> > privileges, populating each chrooted home folder with a specific set of
> > permissions (as is what appears to me to have happened with pkg_add).
> Since
> > pledge's promises can make it where you can execute a file without read
> > permission, it seems ideal to continue that tradition with the paths
> >
> >   On Sat, Sep 3, 2016, 03:07 Luke Small <lukensm...@gmail.com> wrote:
> >>
> >> In pledge, presumably there will be an accessible paths list. Maybe you
> >> grant a process root access, and you need to read a file which is only
> >> granted by root access, and you need write access for another file, so
> the
> >> pledge permissions reflect that. On the presumed current path, you would
> >> leave write access for the first file and maybe you don't need the
> process
> >> to have read permissions on an execl() program. You can prohibit your
> >> process from reading your software or binary, even if it may have
> >> permissions to do so.
> >>
>
> That's not a specific use case.
> Either you should provide a patch or an exemple of a real program that
> is limited by the current design of pledge.
>
> Currently, if you want a program that can only read a file, you pledge
> rpath. If you want the ability to exec file, you pledge exec.
>
> If you want a program that can exec a set of file and write in
> another, either you run your program as a user and group that can't
> write the set of file you want to exec (W^X) or you write two program,
> one pledging for write the other for read.
>
> There following paper have an exemple of how the second design can be done.
> http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html
>
>
> --
>
> Cordialement, Coues Ludovic
> +336 148 743 42



Re: might it be better to have three paths lists

2016-09-03 Thread Luke Small
In pledge, presumably there will be an accessible paths list. Maybe you
grant a process root access, and you need to read a file which is only
granted by root access, and you need write access for another file, so the
pledge permissions reflect that. On the presumed current path, you would
leave write access for the first file and maybe you don't need the process
to have read permissions on an execl() program. You can prohibit your
process from reading your software or binary, even if it may have
permissions to do so.

On Sat, Sep 3, 2016, 02:34 ludovic coues <cou...@gmail.com> wrote:

> What is the use case ?
>
> 2016-09-03 4:15 GMT+02:00 Luke Small <lukensm...@gmail.com>:
> > wouldn't it be more secure to have a write, read, and execute capable
> paths
> > lists in pledge()
> >
>
>
>
> --
>
> Cordialement, Coues Ludovic
> +336 148 743 42



  1   2   >