Re: npppd: simplify and lock down priv_open()

2016-01-06 Thread Todd C. Miller
On Fri, 01 Jan 2016 10:55:14 -0800, Philip Guenther wrote: > Finally got back to this; this diff should fix open(O_NONBLOCK) of bpf, > tun, and tap devices. The bikeshed question is whether this should use > O_NONBLOCK or FNONBLOCK... OK millert@ though I would have used FNONBLOCK. - todd

Re: npppd: simplify and lock down priv_open()

2016-01-04 Thread YASUOKA Masahiko
I'm sorry for delay. ok yasuoka tested. On Fri, 1 Jan 2016 10:55:14 -0800 Philip Guenther wrote: > On Fri, 4 Dec 2015, Todd C. Miller wrote: >> On Fri, 04 Dec 2015 09:47:46 -0800, Philip Guenther wrote: >> > We should fix open(2); please try the diff below. Are you sure

Re: npppd: simplify and lock down priv_open()

2016-01-01 Thread Philip Guenther
On Fri, 4 Dec 2015, Todd C. Miller wrote: > On Fri, 04 Dec 2015 09:47:46 -0800, Philip Guenther wrote: > > We should fix open(2); please try the diff below. Are you sure pppx > > is affected? pppxioctl()'s FIONBIO case appears to be a no-op. I > > certainly agree that bpf and tun are affected.

Re: npppd: simplify and lock down priv_open()

2015-12-04 Thread YASUOKA Masahiko
Hi, On Sat, 10 Oct 2015 21:32:29 -0700 Philip Guenther wrote: > So: > * kill the 'mode' argument to PRIVSEP_OPEN and priv_open() > * fail a PRIVSEP_OPEN call if it's passed any flags other than >O_ACCMODE or O_NONBLOCK > * paranoia: mask O_CREAT when calling open()

Re: npppd: simplify and lock down priv_open()

2015-12-04 Thread Philip Guenther
On Fri, Dec 4, 2015 at 3:41 AM, YASUOKA Masahiko wrote: > On Sat, 10 Oct 2015 21:32:29 -0700 > Philip Guenther wrote: >> So: >> * kill the 'mode' argument to PRIVSEP_OPEN and priv_open() >> * fail a PRIVSEP_OPEN call if it's passed any flags other than

Re: npppd: simplify and lock down priv_open()

2015-12-04 Thread YASUOKA Masahiko
On Fri, 4 Dec 2015 09:47:46 -0800 Philip Guenther wrote: > On Fri, Dec 4, 2015 at 3:41 AM, YASUOKA Masahiko wrote: >> On Sat, 10 Oct 2015 21:32:29 -0700 >> Philip Guenther wrote: >>> So: >>> * kill the 'mode' argument to

Re: npppd: simplify and lock down priv_open()

2015-12-04 Thread Todd C. Miller
On Fri, 04 Dec 2015 09:47:46 -0800, Philip Guenther wrote: > We should fix open(2); please try the diff below. Are you sure pppx > is affected? pppxioctl()'s FIONBIO case appears to be a no-op. I > certainly agree that bpf and tun are affected. Shouldn't the device open function check for

Re: npppd: simplify and lock down priv_open()

2015-10-11 Thread YASUOKA Masahiko
ok yasuoka, the diff is tested. On Sat, 10 Oct 2015 21:58:02 -0700 Philip Guenther wrote: > On Sat, 10 Oct 2015, Theo de Raadt wrote: >> I don't know the code either, but it is probably better if privsep's had >> more narrow task-specific operations. Like

Re: npppd: simplify and lock down priv_open()

2015-10-10 Thread Theo de Raadt
> Currently, npppd's PRIVSEP_OPEN message (abstracted as priv_open()) > accepts arbitrary open() flags and passes a mode argument. That > seems...unwise. > > In particular, it never passes O_CREAT, so the mode argument isn't needed. > Indeed, the only open 'flags' it needs are O_RDONLY and

Re: npppd: simplify and lock down priv_open()

2015-10-10 Thread Philip Guenther
On Sat, 10 Oct 2015, Theo de Raadt wrote: > I don't know the code either, but it is probably better if privsep's had > more narrow task-specific operations. Like open-specific-file-for-read, > and open log-over-there. Privsep operations should be tightly > specified, not very generic. > >