On Wed, Jul 25, 2018 at 12:29:10PM -0600, Theo de Raadt wrote: > >I went over this for a while and i don't see how firefox could be adapted to > >avoid this new pledge class. The other option is to move lots of code around > >so > >that the video device is opened/configured inconditionally by the main > >process > >before pledging (but then you'd still need the various ioctls getting buffers > >etc), but that feels stupid: why would you want to open the video device if > >you're not going to actually use it ? > > Most privsep programs contain a process which isn't pledged.
Except the privsep programs usually follow a model of 'a master process doing init, opening priviledged devices, then orchestrating the others/passing fds'. Here, we're talking about the main firefox process, which does shitloads of things, among those orchestrate the content processes, but also & mostly filesystem access, network access, etc, etc . You'd prefer having it unpledged ? I don't understand your argument here. > >That of course doesn't try to solve the video device access/ownership which > >is > >a separate issue. > > I fear it solves no issues at all. > > As I said before, I am uncomfortable pushing this policy mechanism into > the kernel to be used by *only one program*. I never said it was *only* for firefox. Right now, any program using the v4l api can't be pledged or then loses the ability to talk to the camera device. Ok, in base there's only video(1), but in ports there's mplayer, ffmpeg, vlc, gstreamer, sane, etc.. I know blindly adding pledge everywhere in the ports tree isnt a primary target, but i think huge programs with big attack surface (like all the video players) would be good contenders. I'm not volunteering for them, but i'd like to allow OpenBSD users to 'easily' use video chat in their browser, without having to resort to skype or hangouts on their jesus laptops, or to go through knobs to disable pledge. > Sorry, but that isn't how pledge is developed / extended. I thought it was developed by experimenting with things, and then iterating on them. As far as i see from the cvs log for the pledge kernel subsystem and the basesystem programs conversion, that's how it was developed. Start with a set of syscalls subsets, then add a new syscall to a subset when needed because it's a valid usecase (or change the program behaviour to hoist the syscall usage), or separate a set of syscalls in a new class. I don't see how different the video pledge i'm proposing is from the other classes of syscalls that were added for bpf/drm/tape/audio/disklabel/pf/tty/route. They were all added to allow for a subset of ioctls on a particular type of device. How is my approach different here ?
