Possible negative index on ieee80211_ra.c

2021-03-25 Thread Ricardo Mestre
Hi, As the comment already explains `mcs' may come invalid from the the hardware and then code uses it as index before actually checking its value. The patch below adjusts it so that it's only used after the check. Reported on CID 1502921. Only compile tested. Comments, OK? Index:

Possible null deref on pf.c

2021-02-12 Thread Ricardo Mestre
Hi, This was reported on CID 1501718, ifp starts as NULL and then might be deref'ed. The question is does the below make any sense to solve it since I don't know what I'm doing? :) What do you net gurus say? Index: pf.c === RCS

Add missing break statement on if_rge.c

2021-02-11 Thread Ricardo Mestre
Hi, Add missing break statement. OK? CID 1501710 Index: if_rge.c === RCS file: /cvs/src/sys/dev/pci/if_rge.c,v retrieving revision 1.11 diff -u -p -c -u -r1.11 if_rge.c --- if_rge.c24 Dec 2020 06:34:03 - 1.11 +++

Uninitialized var in dev/pv/vmt.c

2021-02-11 Thread Ricardo Mestre
Hi, Uninitialized var and it's used in a condition != NULL a little bit afterwards. CID 1501713 OK? Index: vmt.c === RCS file: /cvs/src/sys/dev/pv/vmt.c,v retrieving revision 1.22 diff -u -p -u -r1.22 vmt.c --- vmt.c 15 Jan

Re: Swapped arguments on stoeplitz_ip{4,6}port

2021-02-11 Thread Ricardo Mestre
forget about it, patrick@ was way faster and it's already commited :)

Swapped arguments on stoeplitz_ip{4,6}port

2021-02-11 Thread Ricardo Mestre
Hi, It seems this got the args swapped as described in CID 1501717. stoeplitz_ip6port being a macro for stoeplitz_hash_ip6port and the arguments placed as shown below. Similarly stoeplitz_ip4port also has the same problem most likely due to copypasto. Comments? OK? 173 uint16_t 174

Re: Hiding the vim user in amdgpu_vcn.c (typo in comment)

2021-01-05 Thread Ricardo Mestre
Hi, This issue is present in upstream [0], please take it with them. [0] https://sourcegraph.com/github.com/torvalds/linux@30bb5572ce7a8710fa9ea720b6ecb382791c9800/-/blob/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c#L131 On 13:21 Tue 05 Jan , Stefan Hagen wrote: > Hi, > > I can totally relate

Re: panic on inteldrm attach in braswell device

2020-07-10 Thread Ricardo Mestre
the machine is still not properly setup and I didn't want to "pollute" bugs@ without a proper sendbug(1), sorry about that. that being said just tested booting the machine without the hdmi cable to stop inteldrm from attaching, but after everything is booted then attaching the cable makes

panic on inteldrm attach in braswell device

2020-07-10 Thread Ricardo Mestre
Hi, Since my edgerouter decided to commit seppuku, then to replace it, the cheap bastard in me bought a crappy braswell based device which after 2 months finally arrived, but of course it had to have at least one problem. As soon as inteldrm attach I get the below panic, but with inteldrm

Re: ldpd engine process exits with pledge "cpath"

2020-06-19 Thread Ricardo Mestre
this is getting in my nerves, I made a wrong assumption here and I prefer to commit this than backout my previous commit so I'm asking for commits for the below. On 14:43 Fri 19 Jun , Ricardo Mestre wrote: > mea culpa, but I'd rather just remove the unlink of the socket. > > OK? &

Re: ldpd engine process exits with pledge "cpath"

2020-06-19 Thread Ricardo Mestre
mea culpa, but I'd rather just remove the unlink of the socket. OK? Index: control.c === RCS file: /cvs/src/usr.sbin/ldpd/control.c,v retrieving revision 1.29 diff -u -p -u -r1.29 control.c --- control.c 3 Mar 2017 23:30:57 -

unveil(2) relayd(8)'s main proc, now for real

2020-06-18 Thread Ricardo Mestre
Hi, Yes, this is a really broad permission to give but it's needed in order to read the config file (and those ones included from it) and also to exec the "check script(s)" which I missed in my last attempt to unveil(2) relayd(8). The reason it cannot be pledge(2)d is due to forbidden ioctls(2)s

unveil(2) login_chpass(8)

2020-06-18 Thread Ricardo Mestre
Hi, login_chpass(8) only needs access to exec login_lchpass(8), so the below unveils it accordingly. Comments? OK? Index: login_chpass.c === RCS file: /cvs/src/libexec/login_chpass/login_chpass.c,v retrieving revision 1.21 diff -u

Re: [PATCH] from.c: stricter pledge(2)

2020-05-28 Thread Ricardo Mestre
this is ok mestre@ may I commit it? On 21:18 Thu 28 May , Martin Vahlensieck wrote: > Hey! > > This pledge was added with the use of unveil(2), but doesn't require the > getpw promise anymore (it is only needed in mail_spool to get the > username). > > This patch makes it stricter. > >

Re: pledge(2) sndioctl(1)

2020-05-22 Thread Ricardo Mestre
ioctl_ondesc(hdl, ondesc, NULL)) { fprintf(stderr, "%s: can't get device description\n", devname); exit(1); On 08:25 Fri 22 May , Sebastien Marie wrote: > On Fri, May 22, 2020 at 06:57:00AM +0200, Sebastien Marie wrote: > > On Thu, May 21, 2020 at 11:07:39PM +0100, R

pledge(2) sndioctl(1)

2020-05-21 Thread Ricardo Mestre
Hi, After the handle sioctl_hdl `hdl' is opened (which in itself requires rw fs access and opening an unix socket) then all operations happen over that handle so the program may be restricted to only "stdio". All options were tested successfully, including the examples from the manpage plus

Fix typo on if_mcx.c

2020-04-23 Thread Ricardo Mestre
Hi, This one looks like a typo and might cause a double free. CID 1492713 OK? Index: if_mcx.c === RCS file: /cvs/src/sys/dev/pci/if_mcx.c,v retrieving revision 1.43 diff -u -p -u -r1.43 if_mcx.c --- if_mcx.c21 Apr 2020

Re: umb(4) WIP diff and questions

2020-01-22 Thread Ricardo Mestre
Hi, Disclaimer: I don't have such hardware to test with or without the diff below, but I think if we add this change in any shape or form then we should add this as well otherwise we could bump into the vuln [0] that Ilja found on NetBSD which could leak the credentials. [0]

Re: unveil radioctl/fdformat/gpioctl

2019-12-20 Thread Ricardo Mestre
Hello fellow citizens! Did we have any brave souls with the hardware below that tested this and can give me an OK? On 18:57 Mon 02 Dec , Ricardo Mestre wrote: > Hi tech@ > > radioctl/fdformat/gpioctl need to open the device and then all operations go > through ioctls forbidd

unveil radioctl/fdformat/gpioctl

2019-12-02 Thread Ricardo Mestre
Hi tech@ radioctl/fdformat/gpioctl need to open the device and then all operations go through ioctls forbidden by pledge but no further filesystem access is needed so it can be disallowed right afterwards. CAVEAT: The sources for these applications are simple enough to follow, but unfortunately

Re: unveil(2) pcidump(8)

2019-11-29 Thread Ricardo Mestre
err(1, "unveil"); + if (hex > 1) size = 256; if (hex > 2) On 15:01 Fri 29 Nov , Ricardo Mestre wrote: > Hi, > > pcidump(8) only opens devices in O_RDONLY from /dev, and additionally writes a > `romfile' if -r is used, but since I'm

Re: unveil(2) pcidump(8)

2019-11-29 Thread Ricardo Mestre
My emails are getting delayed, I sent another one with unveil(NULL, NULL) right afterwards :) On 10:05 Fri 29 Nov , Theo de Raadt wrote: > Klemens Nanni wrote: > > > On Fri, Nov 29, 2019 at 03:01:45PM +0000, Ricardo Mestre wrote: > > > All combination of parameters were

unveil(2) usbdevs(8)

2019-11-29 Thread Ricardo Mestre
Hi, usbdevs(8) only needs to open devices in O_RDONLY mode from /dev Comments? OK? Index: usbdevs.c === RCS file: /cvs/src/usr.sbin/usbdevs/usbdevs.c,v retrieving revision 1.31 diff -u -p -u -r1.31 usbdevs.c --- usbdevs.c 14 Apr

unveil(2) pcidump(8)

2019-11-29 Thread Ricardo Mestre
Hi, pcidump(8) only opens devices in O_RDONLY from /dev, and additionally writes a `romfile' if -r is used, but since I'm only unveiling after that file is actually opened there's no need to unveil it as well. All combination of parameters were tested, comments, OK? Index: pcidump.c

Reduce pledge(2) on file(1)'s main proc

2019-11-29 Thread Ricardo Mestre
Hi, After fork(2) the main proc needs rpath for {l,}stat/open and sendfd for imsg_* to send fds to the child proc which is already pledged by recvfd to receive them. Still passes regress tests, OK? Index: file.c === RCS file:

Re: rad unveil

2019-11-27 Thread Ricardo Mestre
Hi benno, If you remove "include" then please make the unveil next to pledge like the below, that way we know right away why exactly we need rpath for in pledge. Also, you only need unveil(NULL, NULL) if you're not actually calling pledge somewhere down the code. Index: rad.c

unveil vmd(8)'s priv process

2019-08-26 Thread Ricardo Mestre
Hi, Currently vmd(8) has 3 processes that run under chroot(2)/chdir(2), namely control, vmm and priv. From these both control and vmm already run under different pledge(2)s but without any filesystem access, priv in the other hand cannot use pledge due to forbidden ioctls. That being said the

unveil(2) missing codepath on dhcpd(8)

2019-08-07 Thread Ricardo Mestre
Hi, One missing piece when I added pledge(2) to dhcpd(8) was in the code path when it's invoked with either -A/-C/-L, which at the time I left alone due to some forbidden ioctls by pledge(2). Now we have unveil(2) and this path can be further restricted by using it instead of chroot(2) since

Re: remove chroot(2) from spamd(8)

2019-07-31 Thread Ricardo Mestre
As I already spoke with Theo this needs to be carefully looked app by app and not remove chroot just because, it needs to make sense first and foremost. This diff was also not one by random choice, spamd(8) was one of the first programs I actually studied, pledge(2)d it and use daily and sent it

remove chroot(2) from spamd(8)

2019-07-31 Thread Ricardo Mestre
Hi, By now we are already confident that pledge(2) "just works(tm)" and that it can be used to effectively remove filesystem access. That being said, in spamd(8) when I pledge(2)d it the main priv process got "stdio inet" which means there's no fs access at all so calling chroot(2)/chdir(2) here

Re: update acct(5)

2019-07-29 Thread Ricardo Mestre
this surely looks better than mine ok mestre@ On 14:25 Mon 29 Jul , Todd C. Miller wrote: > On Mon, 29 Jul 2019 18:14:14 +0100, Ricardo Mestre wrote: > > > Sorry, I'm not too good with words for manpages. > > > > Is this good enough? I'll commit the AUNVEIL bit se

Re: update acct(5)

2019-07-29 Thread Ricardo Mestre
AUNVEIL +respectively. .Sh SEE ALSO .Xr lastcomm 1 , .Xr acct 2 , .Xr execve 2 , +.Xr pledge 2 , +.Xr unveil 2 , .Xr accton 8 , .Xr sa 8 .Sh HISTORY On 08:47 Mon 29 Jul , Todd C. Miller wrote: > On Mon, 29 Jul 2019 13:55:32 +0100, Ricardo Mestre wrote: > > > Now that thi

update acct(5)

2019-07-29 Thread Ricardo Mestre
Hi, Now that this is already being used in kernel and userland the manpage for acct(5) needs to be updated. Comments? OK? Index: acct.5 === RCS file: /cvs/src/share/man/man5/acct.5,v retrieving revision 1.16 diff -u -p -u -r1.16

remove BUGS section from spamd(8)

2019-07-24 Thread Ricardo Mestre
Hi, Ever since I introduced pledge(2) on spamd(8) the chroot'ed process, if running in default, cannot get anywhere near the filesystem since its only promises are "stdio inet". Furthermore, in blacklist mode this same codepath is not chroot'ed but once again it gets the same pledge(2). That

Re: ssh needs sendfd in pledge call?

2019-07-23 Thread Ricardo Mestre
Hi, As Timothy reported, and with the options he selected for ssh then the codepath taken will call mux_client_request_session -> mm_send_fd -> sendmsg(2). Since sendmsg(2) is not allowed in that codepath then pledge(2) kills the process. Please see below the trace he provided privately, and

Remove duplicate pledge(2) from tsort(1)

2019-07-11 Thread Ricardo Mestre
Hi, pledge "stdio rpath" is already called in main(), so we can remove the duplicate from parse_args(), along with the pledge commented out from another era! The second part is about placing pledge "stdio" in main() instead for better readability (at least for me). No functional change is

Re: unveil(2) switchd(8)

2019-07-11 Thread Ricardo Mestre
Of course when I mention in the second option to "unveil" / it's just to call pledge with rpath, not actually calling unveil(2). On 10:20 Thu 11 Jul , Ricardo Mestre wrote: > Hi, > > switchd(8)'s main proc needs to open the following paths, and which can be > un

unveil(2) switchd(8)

2019-07-11 Thread Ricardo Mestre
Hi, switchd(8)'s main proc needs to open the following paths, and which can be unveiled: / -> read, it will open config files from anywhere in the system, and also needs to open /etc/services /dev -> read/write, in order to open /dev/tap* and /dev/switch* Just before the main loop the devices

Re: ldpd(8): unveil(2) main proc / reduce pledge(2) on ldpe

2019-07-11 Thread Ricardo Mestre
The third's the charm? :) OK? On 20:23 Fri 14 Jun , Ricardo Mestre wrote: > ping? > > On 12:33 Wed 22 May , Ricardo Mestre wrote: > > Hi, > > > > Like we did on other daemons that cannot be pledged due to forbidden ioctls > > the > > main process

Re: unveil dhclient (privileged process)

2019-07-11 Thread Ricardo Mestre
Since krw@ gave me feedback on yet another way to handle the defines I'd rather leave that alone for now, it can be left as an exercise later on as you point out. I'll go ahead and commit this instead if no one objects. Index: dhclient.c

Re: unveil dhclient (privileged process)

2019-07-10 Thread Ricardo Mestre
strlen(contents); n = write(fd, contents, sz); if (n == -1) - log_warn("%s: write(%s)", log_procname, path); + log_warn("%s: write(%s)", log_procname, _PATH_RESOLV_CONF); else if ((size_t)n < sz) log_war

Re: unveil(2) sysctl(8)

2019-06-15 Thread Ricardo Mestre
sure, it wasn't mine! it was just missing one unveil so it's ok mestre@ on this one On 11:42 Sat 15 Jun , Theo de Raadt wrote: > yeah that was my idea.. > > Ricardo Mestre wrote: > > > Hi, > > > > Sorry to be late in the game, but as jca@ pointed o

Re: ldpd(8): unveil(2) main proc / reduce pledge(2) on ldpe

2019-06-14 Thread Ricardo Mestre
ping? On 12:33 Wed 22 May , Ricardo Mestre wrote: > Hi, > > Like we did on other daemons that cannot be pledged due to forbidden ioctls > the > main process can be unveiled to restrict filesystem access. In this case we > can > restrict it to only read, although

Re: unveil(2) sysctl(8)

2019-06-14 Thread Ricardo Mestre
err(1, "unveil"); > if (argc == 0 || (Aflag || aflag)) { > debuginit(); > vfsinit(); > @@ -893,7 +901,6 @@ parse(char *string, int flags) > } > if (special & BOOTTIME) { > struct timeval *btp = (struct time

Re: unveil(2) sysctl(8)

2019-06-07 Thread Ricardo Mestre
18:14 Fri 07 Jun, Ricardo Mestre wrote: > > Hi, > > > > My eyes may be cheating me in plain sight, but sysctl(8) doesn't seem to > > require fs access at all. > > > > Comments? OK? > > > > Index: sysctl.c > > =

unveil(2) sysctl(8)

2019-06-07 Thread Ricardo Mestre
Hi, My eyes may be cheating me in plain sight, but sysctl(8) doesn't seem to require fs access at all. Comments? OK? Index: sysctl.c === RCS file: /cvs/src/sbin/sysctl/sysctl.c,v retrieving revision 1.242 diff -u -p -u -r1.242

Re: pledge(2) unbound-checkconf(8)

2019-05-23 Thread Ricardo Mestre
it must be one of those days... it's ok mestre if you feel like commiting it and doesn't add any burden for you when upgrading unbound. On 13:18 Thu 23 May , Stuart Henderson wrote: > check_mod(cfg, val_get_funcblock()); > > - needs to read the DNSSEC root key, > >

Re: pledge(2) unbound-checkconf(8)

2019-05-23 Thread Ricardo Mestre
bonkers my brain must have farted :\ rpath should be dropped after loading the certs. I just tested it with remote-control with certificates, could you please let me know if it works for you now? Index: unbound-checkconf.c === RCS

pledge(2) unbound-checkconf(8)

2019-05-22 Thread Ricardo Mestre
Hi, unbound-checkconf(8) needs to chdir(2) and then open(2) the config file and to call getpwnam(3). This means it needs to pledge for rpath and getpw, but after calling getpwnam(3) the config file was already loaded so we can drop both promises afterwards. Comments? OK? Index:

ldpd(8): unveil(2) main proc / reduce pledge(2) on ldpe

2019-05-22 Thread Ricardo Mestre
Hi, Like we did on other daemons that cannot be pledged due to forbidden ioctls the main process can be unveiled to restrict filesystem access. In this case we can restrict it to only read, although it must be the entire / since the daemon is able to include config files from anywhere.

Re: drop rpath from openssl(1) ciphers

2019-04-30 Thread Ricardo Mestre
At least it went through ktrace -di, with all flags tested, without opening any files. Let's see what the crypto guys say :) On 12:12 Tue 30 Apr , Theo de Raadt wrote: > I am a bit sceptical, and worry that some internal function may > do something. > > > openssl ciphers doesn't seem to

drop rpath from openssl(1) ciphers

2019-04-30 Thread Ricardo Mestre
Hi, openssl ciphers doesn't seem to need to open any files to show the full list of ciphers, or manually selected so drop rpath from pledge. OK? Index: ciphers.c === RCS file: /cvs/src/usr.bin/openssl/ciphers.c,v retrieving

Re: unveil chpass

2019-04-30 Thread Ricardo Mestre
Here's another one also pending to apply unveil(2) on chpass(1) OK? On 12:58 Wed 07 Nov , Ricardo Mestre wrote: > Hi, > > chpass(1) without parameters enters in edit mode by default, in here it will > need to execute _PATH_BSHELL to spawn a new EDITOR, _PATH_SHELLS to check &g

Re: unveil tcpdrop

2019-04-30 Thread Ricardo Mestre
Went through my old sent emails and saw this one still pending on my tree. Is this OK? On 13:02 Wed 07 Nov , Ricardo Mestre wrote: > Hi, > > tcpdrop(8) needs to access only two files, in this case /etc/hosts and > /etc/resolv.conf both with read permissions for the pur

unveil relayd

2019-04-22 Thread Ricardo Mestre
Hi, I had a patch with pledge(2) for quite a while ago, but my setup is too simple and cannot test it enough so at least we can have restricted read access to the fs in relayd(8)'s main process through unveil(2). Comments? OK? Index: relayd.c

unveil hotplugd

2019-04-22 Thread Ricardo Mestre
Hi, Now that I'm finally on my new home and tree is opened again... hotplugd(8) needs to open(2) `device' with read permissions, /dev/hotplug by default but can be changed via arguments. Then it needs read/execute on both _PATH_ETC_HOTPLUG_{ATTACH,DETACH} to access(2) and execl(3) them. Tested

Re: YP/NIS support in /etc/ethers, libc ether_ntohost/ether_hostton

2018-11-09 Thread Ricardo Mestre
Paraphrasing an excerpt of my commit on getent(1) to add unveil(2): "After a discussion with millert@ regarding YP then deraadt@ chimed in referring that when he wrote this code even though we can have YP mappings with several of these dbs "it doesn't mean that things use it, or should, or will"

Re: unveil error - src/usr.bin/passwd/local_passwd.c (-current)

2018-11-08 Thread Ricardo Mestre
Hi Mark, Thanks for the report, don't know how I missed it but it's now fixed. On 16:20 Thu 08 Nov , Mark Patruck wrote: > Hi Ricardo, > > when running > > $ passwd > > with src/usr.bin/passwd/local_passwd.c v1.54 > > i see the following error in /var/log/messages > > passwd: cannot

Re: tcpdump: revisiting some old diffs, cleanup unused functions

2018-11-08 Thread Ricardo Mestre
Still works as advertised, ok mestre@ On 19:32 Wed 07 Nov , Bryan Steele wrote: > On Wed, Nov 07, 2018 at 07:06:09PM -0500, Bryan Steele wrote: > > I'm revisiting some old tcpdump diffs, now that mestre@ has added proper > > unveil(2) support! :-) > > > > Refresher:

unveil hotplugd

2018-11-07 Thread Ricardo Mestre
Hi, hotplugd(8) needs to open(2) `device' with read permissions, /dev/hotplug by default but can be changed via arguments. Then it needs read/execute on both _PATH_ETC_HOTPLUG_{ATTACH,DETACH} to access(2) and execl(3) them. Tested successfully attaching/dettaching (mount/umount) an USB pen.

unveil tcpdrop

2018-11-07 Thread Ricardo Mestre
Hi, tcpdrop(8) needs to access only two files, in this case /etc/hosts and /etc/resolv.conf both with read permissions for the purpose of name resolution. ethers(5) is not needed since we are not using any of the ether_*(3) family. Since unistd.h needs to be included I also shuffled netdb.h into

unveil chpass

2018-11-07 Thread Ricardo Mestre
Hi, chpass(1) without parameters enters in edit mode by default, in here it will need to execute _PATH_BSHELL to spawn a new EDITOR, _PATH_SHELLS to check (read) if we are changing from/to a non-standard shell (in case we are not root) and read access to `tempname' to verify if the file has valid

Re: unveil dhclient (privileged process)

2018-11-05 Thread Ricardo Mestre
something like the below? I added a new define for /etc/resolv.conf since it's now used on 2 different places and hardcoded the executable path to avoid strange errors if running from a symlink directory as pointed out by remi@ Index: dhclient.c

Re: unveil dhclient (privileged process)

2018-11-05 Thread Ricardo Mestre
As per krw@ I probably should add a #define to /sbin/dhclient and use that instead of saved_argv and you wouldn't have that error but you'd still have to make install. On 22:53 Mon 05 Nov , Remi Locherer wrote: > On Mon, Nov 05, 2018 at 12:30:08PM +0000, Ricardo Mestre wrote: >

unveil dhclient (privileged process)

2018-11-05 Thread Ricardo Mestre
Hi, dhclient(8)'s privileged process cannot be pledged yet due to some route related sysctl(2)'s, but it seems it only needs to access two files. One is /etc/resolv.conf with write/create permissions and saved_argv[0] (usually /sbin/dhclient) with execute since we may receive a SIGHUP and it will

Re: pledge xenodm

2018-11-03 Thread Ricardo Mestre
this is actually good, I made it as minimal as possible so that it wouldn't break for me, if it breaks for you we can start from there. On 13:41 Sat 03 Nov , Matthieu Herrb wrote: > On Fri, Nov 02, 2018 at 07:03:11PM +0000, Ricardo Mestre wrote: > > Hi, > > > > Looki

Re: pledge xenodm

2018-11-03 Thread Ricardo Mestre
prodded by deraadt@, here's a rebased diff on xenocara's source root directory, usually /usr/xenocara. Index: app/xenodm/xenodm/dm.c === RCS file: /cvs/xenocara/app/xenodm/xenodm/dm.c,v retrieving revision 1.6 diff -u -p -u -r1.6

Re: disable fs access on ripd

2018-11-03 Thread Ricardo Mestre
reads OK for me as well On 10:28 Sat 03 Nov , Claudio Jeker wrote: > On Sat, Nov 03, 2018 at 10:24:23AM +0100, Remi Locherer wrote: > > On Tue, Oct 30, 2018 at 05:31:04PM +, Ricardo Mestre wrote: > > > clearly an oversight due to looking at too many daemons at the same

pledge xenodm

2018-11-02 Thread Ricardo Mestre
Hi, Looking at pledging xenodm a little bit more I was able to run it with the diff below across X restarts, with stock configuration. Please test it, if you have special configs better since most likely this will break it but we need to know where and why and with that maybe trim xenodm's

Re: disable fs access on ripd

2018-10-30 Thread Ricardo Mestre
21:53 Tue 30 Oct , Sebastian Benoit wrote: > Florian Obser(flor...@openbsd.org) on 2018.10.30 18:32:15 +0100: > > On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote: > > > Remi Locherer wrote: > > > > > > > On Tue, Oct 30, 2018 at 03:20:35PM

Re: disable fs access on ripd

2018-10-30 Thread Ricardo Mestre
nveil"); + if (unveil(NULL, NULL) == -1) + fatal("unveil"); + event_dispatch(); ripe_shutdown(); On 11:15 Tue 30 Oct , Theo de Raadt wrote: > Remi Locherer wrote: > > > On Tue, Oct 30, 2018 at 10:54:10AM -0600, Theo de Raadt wrote:

disable fs access on ripd

2018-10-30 Thread Ricardo Mestre
Hi, After all files are opened ripd(8) can have the fs access disabled just before each process main loop. Its 2 childs already run under chroot, but since they are still not pledged at least they have no way to read/write/create files within the chroot. No loads or reloads of the config file

disable fs access on snmpd

2018-10-30 Thread Ricardo Mestre
Hi, snmpd(8)'s main process needs to open the config file and /dev/pf both with read permissions, but once it reaches pledge(2) just before the main loop both were already opened. Since snmpd(8) doesn't have a way to load or reload the config file, not even through SIGHUP, then rpath promise is

unveil ifstated

2018-10-30 Thread Ricardo Mestre
Hi, ifstated(8) needs to load configfile from within the main loop, but also to reload it on SIGHUP so unveil(2) it with read permissions. Additionally all commands are exec'ed through /bin/sh instead of directly so we can just unveil(2) /bin/sh with x perms. Since /bin/sh is already used on

unveil htpasswd

2018-10-30 Thread Ricardo Mestre
Hi, htpasswd(1) when in batch mode (-I) and 1 argument is used, or when not in batch mode and 2 arguments are used we know we have to access argv[0] with rwc permissions and also to rwc a temporary file in /tmp so we can unveil(2) both argv[0] and /tmp with rwc permissions. In order to avoid

Re: unveil ospfd's parent proc

2018-10-28 Thread Ricardo Mestre
Not all daemons have the same behaviour, so if this is still used then Remi's diff of course makes more sense. On 19:24 Sun 28 Oct , Sebastian Benoit wrote: > Ricardo Mestre(ser...@helheim.mooo.com) on 2018.10.28 17:26:24 +: > in ospfd, ospf6d (and hopefully soon bgpd) we mak

Re: unveil ospfd's parent proc

2018-10-28 Thread Ricardo Mestre
Correct, and I'd go even further by not unveiling the socket at all. A few weeks ago I removed the logic of unlinking the socket when the program stops, for a few daemons, but left untouched the ones that don't have the main process pledged since it wouldn't make much difference. If we want to go

unveil getconf

2018-10-25 Thread Ricardo Mestre
Hi, The code path were we pass `pathname' in the arguments is already limited with pledge(2), but since we know exactly what it is then we can go further and also unveil(2) it with read permissions. Comments? OK? Index: getconf.c

unveil kvm_mkdb

2018-10-25 Thread Ricardo Mestre
Hi, If we pass `file' via args then we need to unveil(2) it with read permission, otherwise if omitted we need to unveil(2) both _PATH_UNIX and _PATH_KSYMS with same permissions. Unconditionally we need to also unveil(2) dbdir, which by default is _PATH_VARDB but can be changed via args (-o

Re: unveil bdftopcf

2018-10-25 Thread Ricardo Mestre
Something like this then? If it's too much burden to keep these local patches I can drop it, no problem. Index: bdftopcf.c === RCS file: /cvs/xenocara/app/bdftopcf/bdftopcf.c,v retrieving revision 1.5 diff -u -p -u -r1.5 bdftopcf.c

unveil bdftopcf

2018-10-24 Thread Ricardo Mestre
Hi, If input_name is provided we can unveil it with read permissions, if output_name is provided we need to unveil this one with rwc. Additionally depending on the different combinations of if these files are passed via args or from stdin/to stdout we can also pledge accordingly to the code path.

Re: unveil xserver's priv proc

2018-10-24 Thread Ricardo Mestre
Hello, semarie@ already gave positive feedback for unveiling xserver, did anyone tested it yet and comment on it or OK? Index: privsep.c === RCS file: /cvs/xenocara/xserver/os/privsep.c,v retrieving revision 1.29 diff -u -p -u

unveil passwd

2018-10-24 Thread Ricardo Mestre
Hi, The diff below unveils passwd with exactly the same ones used on vipw, the only difference is that in this case _PATH_BSHELL is used to spawn an external passwordcheck program (if defined in /etc/login.conf) instead of an EDITOR. Tested by changing my users' passwords back and forth several

unveil spamlogd

2018-10-24 Thread Ricardo Mestre
Hi, The only file that spamlogd needs to access after calling pledge is PATH_SPAMD_DB, so unveil it with O_RDWR permissions. OK? Index: spamlogd.c === RCS file: /cvs/src/libexec/spamlogd/spamlogd.c,v retrieving revision 1.27 diff

unveil spamd

2018-10-23 Thread Ricardo Mestre
Hi, When spamd runs in greylist mode the parent process (which runs greywatcher()) we know that the only files that it will ever access are PATH_SPAMD_DB in rw, alloweddomains_file in r and that it will need to exec PATH_PFCTL so we can unveil them with those permissions. All other necessary

Re: unveil xserver's priv proc

2018-10-16 Thread Ricardo Mestre
Oops I missed the obvious kill(2) only a few lines later, silly me :\ On 13:56 Tue 16 Oct , Sebastien Marie wrote: > about unveil: it seems fine. open_ok() functions checks if > cmd.arg.open.path is in allowed_devices. so having it locked to only > that seems correct. > > > about pledge:

unveil xserver's priv proc

2018-10-16 Thread Ricardo Mestre
Hi, xserver's priv proc is responsible for opening devices in O_RDWR mode and send their fds over to the parent proc. Knowing this then we already have a list of all possible devices that might be opened in the future and we can unveil(2) them by traversing allowed_devices and yes it's a long

Re: savecore: unveil bug

2018-09-28 Thread Ricardo Mestre
Hi Sebastien, I had a similar diff lying around, although with if/else, and forgot about it :\ OK mestre@ if someone wants to commit it and thank you! On 09:03 Fri 28 Sep , Sebastien Marie wrote: > Hi, > > The unveil(2) call for savecore(8) is incomplete. savecore(8) needs to > access to

Re: unveil(2) tcpdump(8)

2018-09-28 Thread Ricardo Mestre
not have been enough to see flaws with the diff. I can't stress this enough, please test it and report it ASAP either here or in private. On 18:08 Wed 26 Sep , Ricardo Mestre wrote: > I'm not too worried about the crash, I was playing with removing rpath > from pledge in the case that /etc/

unveil(2) vipw(8)

2018-09-27 Thread Ricardo Mestre
Hi, I've just commited this to unveil vipw, all the tests I've done were successful and didn't bump into any problems, nevertheless if you get any troubles because of this, like getting locked out of the machine, please let me know ASAP! Index: vipw.c

Re: unveil(2) tcpdump(8)

2018-09-26 Thread Ricardo Mestre
il"); + if (unveil("/etc/rpc", "r") == -1) + err(1, "unveil"); if (pledge("stdio rpath inet dns recvfd bpf", NULL) == -1) err(1, "pledge")

fix usermod -l

2018-09-26 Thread Ricardo Mestre
Hi, While doing something else here I noticed that changing the login name of an existing user with usermod -l the program gets a segmentation fault. This looks like it was introduced when millert@ changed pwcache and the fix is a matter of changing getpwnam(3) to uid_from_user(3). OK? Index:

unveil(2) tcpdump(8)

2018-09-26 Thread Ricardo Mestre
Hi, This has been shown internally for some time, but deraadt@ asked me to show it to a bigger audience now so here it is! If we want OS fingerprinting by using -o flag then we can unveil /etc/pf.os in read mode, nevertheless in order to do this we need to inform the privsep proc that we are

Re: yacc + unveil

2018-09-25 Thread Ricardo Mestre
This is an example of better to start at just hoisting the code that opens the many fds and put them all inside open_files(). After that it's just a matter of calling pledge("stdio") and we are done. Of course that after this is done we can still make a list of all the files we need to open and

Re: unveil(2) getent(1)

2018-09-24 Thread Ricardo Mestre
getpw", NULL) == -1) - err(1, "pledge"); - if (argc < 2) usage(); for (curdb = databases; curdb->name != NULL; curdb++) { On 20:41 Mon 24 Sep , Klemens Nanni wrote: > On Mon, Sep 24, 2018 at 10:49:42AM +0100, Ricardo M

Re: unveil(2) getent(1)

2018-09-24 Thread Ricardo Mestre
Oh boy, I took a brief look into Makefile.yp(8), let's forget about this since ALL of them can have YP maps (except for /etc/shells). On 06:20 Mon 24 Sep , Todd C. Miller wrote: > On Mon, 24 Sep 2018 12:25:51 +0100, Ricardo Mestre wrote: > > > Wouldn't this be already contemplat

Re: unveil(2) getent(1)

2018-09-24 Thread Ricardo Mestre
Wouldn't this be already contemplated by pledge(getpw) on both group and passwd databases? I'm not touching those since they already whitelist all necessary files through pledge(2). On 05:11 Mon 24 Sep , Todd C. Miller wrote: > I doubt this will work on systems using YP or ypldap. > > -

unveil(2) getent(1)

2018-09-24 Thread Ricardo Mestre
Hi, Since the databases that require rpath only need to access one file we can add one attribute to the struct getentdb to identify which of those DBs we need unveiled. For group/hosts/passwd the files are already whitelisted through pledge(2) so I set them as NULL. With that information we can

Re: uninitialized variable in if_mue.c

2018-09-18 Thread Ricardo Mestre
hash table. */ - memset(hashtbl, 0, sizeof(hashtbl)); /* Now program new ones. */ ETHER_FIRST_MULTI(step, ac, enm); On 09:06 Tue 18 Sep , Claudio Jeker wrote: > On Tue, Sep 18, 2018 at 07:55:43AM +0100, Ricardo Mestre wrote: > > Hi,

uninitialized variable in if_mue.c

2018-09-18 Thread Ricardo Mestre
Hi, In the case that a mue(4) device is put in promiscuous mode then hashtbl will be used uninitialized a little bit down the road so set it 0 like it's done in a lot of other devices. Coverity ID 1473316. OK? Index: if_mue.c ===

  1   2   3   >