Re: Properly unveil(2) the unix socket file in vmctl(8)

if (unveil(SOCKET_NAME, "r") == -1) + if (unveil(SOCKET_NAME, "rw") == -1) err(1, "unveil %s", SOCKET_NAME); if ((ctl_sock = socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0)) == -1) On 11:21 Wed 31 Aug

Properly unveil(2) the unix socket file in vmctl(8)

After discussing with martijn@ if we should keep using unveil(2) (or not), in his latest diff of further privsep'ing snmpd(8), and also after he also spoke with deraadt@, it turns out that unix's promise in pledge(2) is not enforcing the unix socket's file permissions as it should. e.g. Unveiling

Re: rpki-client unveil main process

6PM +0100, Ricardo Mestre wrote: > > We are using pledge so if you don't remove the unveil permission it will be > > allowed throughtout the entire process, so please just change unveil(NULL, > > NULL) > > to old previous pledge("stdio rpath wpath cpath fa

Re: rpki-client unveil main process

We are using pledge so if you don't remove the unveil permission it will be allowed throughtout the entire process, so please just change unveil(NULL, NULL) to old previous pledge("stdio rpath wpath cpath fattr sendfd"). Thank you :) On 12:29 Thu 04 Aug , Claudio Jeker wrote: > On Thu, Aug

Re: Remove support for CH and HS classes from dig(1)

sure you do! otherwise I figure you'd have removed it already :) dropping the diff. On 17:08 Mon 18 Jul , Florian Obser wrote: > yes, I use it daily. > > $ dig @k.root-servers.net +norec +noall +answer hostname.bind ch txt > hostname.bind.0 CH TXT

Remove support for CH and HS classes from dig(1)

Hi, I'm too young to ever know there were other types of networks still supported by dig(1), but it seems it's a thing. Found while reading [0]. Realistically speaking do we want to keep supporting these kind of ancient networks on our version? Is there still someone out there using them? [0]

Re: fix ldapd unveil

yep, ok mestre@ On 20:50 Tue 14 Dec , Theo de Raadt wrote: > I agree. > > Jonathan Matthew wrote: > > > ldapd currently can't reopen its database files, because it always passes > > O_CREAT to open() when reopening (see ldapd_open_request()), which means it > > needs the unveil 'c' flag.

Re: unveil(2) usbhidaction(1)

Hi, and of course this was also missing unveil(NULL, NULL). ok now? this one opens the default table file "/usr/share/misc/usb_hid_usages" through hid_start(3) from libusbhid, then `dev' (will have the fd used on the ioctls) and finally `conf' which is the file with the actions to be monitored.

Re: unveil(2) usbhidctl(1)

Hi, of course it needs that, sorry. ok now? a little bit more of info here, hid_start(3) opens `table' through libusbhid, then usbhidctl(1) itself opens `dev', after that it's just performing ioctls on the fd left opened by the latter in this case `hidfd'. Index: usbhid.c

unveil(2) usbhidctl(1)

Hi, usbhidctl(1) after hid_start(3) doesn't need to open any more files so we can restrict all fs access with unveil(2). comments? ok? Index: usbhid.c === RCS file: /cvs/src/usr.bin/usbhidctl/usbhid.c,v retrieving revision 1.17

unveil(2) usbhidaction(1)

Hi, disclaimer: fortunately people are using ucc(4) instead of usbhidaction(1), the devices I have cannot be tested properly with this diff so please bear with me. this is similar to the diff I sent for usbhidctl(1), the exception is that you can run this as a daemon and `conf' can be re-read on

remove redundant pledge(2)s on who(1)

Hi, There's no need to call pledge(2) so many times, or on many places, with the same promises, just call it once before the switch case while at the same time hoisting one unveil(2) so they are all grouped. The call to pledge(2) on file() can also be simplified since "stdio rpath getpw" will

is rpath needed on rad(8)?

does rad(8) actually need rpath here? as far as i can see it needs to open the config, plus its includes, but that is already done before pledge(2) by imsg sending IMSG_RECONF_CONF. florian@ is this correct or am i trusting too much on my eyes? Index: rad.c

missing explicit_bzero(3) on login_reject(8)

ensure that sensitive data is zeroed out from mem. ok? Index: login_reject.c === RCS file: /cvs/src/libexec/login_reject/login_reject.c,v retrieving revision 1.17 diff -u -p -u -r1.17 login_reject.c --- login_reject.c 26 Apr

Re: unveil(2) stty(1)

> > You can pass lots of -f options, and stty will leak them the fd's. I > suspect it can hit the fd limit before it hits the argv limit. Anyways > just a strange behaviour. > > > Ricardo Mestre wrote: > > > stty(1) can't be pledged for all modes, but it can

unveil(2) stty(1)

stty(1) can't be pledged for all modes, but it can be unveiled. the only file to be opened is on stty -f `file', so call unveil(2) afterwards to restrict all fs access. tested with all arguments through ktrace/kdump. ok? Index: stty.c

Re: Small nit on one of passwd(1)'s unveil(2)

Actually it does a stat(2) on it, forget about this :) On 16:46 Fri 30 Jul , Ricardo Mestre wrote: > Hi, > > _PATH_MASTERPASSWD_LOCK is opened, from libutil, with O_WRONLY|O_CREAT and > then > unlinked when not necessary anymore so it doesn't need read permissions. >

Small nit on one of passwd(1)'s unveil(2)

Hi, _PATH_MASTERPASSWD_LOCK is opened, from libutil, with O_WRONLY|O_CREAT and then unlinked when not necessary anymore so it doesn't need read permissions. OK? Index: local_passwd.c === RCS file:

Re: /etc/ssl/cert.pem doesn't need to be unveiled on ntpd(8)

any comments on the pledge(2) side of things? On 14:12 Thu 08 Jul , Ricardo Mestre wrote: > my eyes may be tricking me, but it looks like the main proc doesn't speak with > sockets during the main loop and setpriority plus privdrop at this point are > all > set and done so ple

Re: /etc/ssl/cert.pem doesn't need to be unveiled on ntpd(8)

(pledge("stdio settime proc exec", NULL) == -1) err(1, "pledge"); while (quit == 0) { On 10:37 Thu 08 Jul , Klemens Nanni wrote: > On Thu, Jul 08, 2021 at 08:43:30AM +0100, Ricardo Mestre wrote: > > /etc/ssl/cert.pem is loaded into mem

/etc/ssl/cert.pem doesn't need to be unveiled on ntpd(8)

Hi, /etc/ssl/cert.pem is loaded into mem with tls_load_file(3) on local function priv_constraint_child() which is called before we reach the code below, therefore we don't need to unveil(2) it nor having pledge(2) "rpath". Comments? OK? Index: ntpd.c

Re: spamd(8) use tls_config_set_{cert,key}_file instead of relying on tls_load_file(3)

:58 Tue 06 Jul , Klemens Nanni wrote: > On Wed, Jun 30, 2021 at 01:11:38PM +0100, Ricardo Mestre wrote: > > Hi, > > > > I may have seen it elsewhere, or probably not, but after checking on kn's > > commit > > to tls_load_file(3) it seems it's now possible to

spamd(8) use tls_config_set_{cert,key}_file instead of relying on tls_load_file(3)

Hi, I may have seen it elsewhere, or probably not, but after checking on kn's commit to tls_load_file(3) it seems it's now possible to set the ca/cert/key directly without having to load them first from disk and set them afterwards from memory. That being said the below applies this to spamd(8),

Re: Rationale behind exec clearing out unveil paths

Hi, I didn't want to reply, but I saw all this thread and had to because it seems you're on some fumes dude. I surely knew before and after my commit that the unveil wound't descend into the child process, what happened in this case was that I actually didn't see that the main process actually

Possible negative index on ieee80211_ra.c

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

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

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

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

forget about it, patrick@ was way faster and it's already commited :)

Swapped arguments on stoeplitz_ip{4,6}port

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)

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

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

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"

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"

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

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)

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)

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)

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)

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

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

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

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

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)

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)

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)

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)

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

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

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

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)

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)

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)

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)

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)

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)

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)

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?

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)

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)

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)

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

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

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

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

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

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

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

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

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

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

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)

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

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

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

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

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)

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)

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)

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   3   >