Ricardo Mestre <[email protected]> wrote: > 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 using -o so I added it to priv_exec().
looks right > The other file needed to be unveiled is /etc/ethers in read mode, which I > tried > to make it conditional but after several successful tests I bumped into a > packet which made tcpdump crash after some time. Unfortunately I don't have > the > core nor the pcap files to investigate what happen so for now the unveil of > this file will be kept unconditional regardless of the flags or expression > used. It is very likely that a protocol parser will find a MAC address nested inside, and try to parse it via /etc/ethers. So makes sense, and there is little risk in exposing ethers There is far more risk that some other file is required, and will fail to open silently, and tcpdump willbehave differently You know well: unveil requires a different audit approach than pledge But it is rare for a missing file via unveil to crash a program, so something is fishy. A crash isn't good, perhaps try to reproduce and collect a corefile using the sysctl kern.nosuidcoredump=3 method.
