configd gates every mutating call on the caller's uid and leaves reads open to anyone who can reach the socket, on purpose, so support can inspect a robot it may not change. system.pairingPin is counted as a read. it is not one. the pin is what authenticates a phone over ble, and once a phone holds it every mutating call on that transport is reachable, net.connect, pad.pair, update.apply, account.login with force. so a peer that may read the pin may change the robot by another route, and the gate on system.setPairingPin is only as strong as the gate on reading it back, which is none.
who can reach the socket is the robot group, and the units put every daemon in it: btd, mediad, padd, tofd. btd needs the pin, it answers the pairing exchange with it, and it is in --allow-user for that. the other three have no reason to hold it. padd is the one the repository describes as the process whose whole value is having no privileged access, and it parses input from whatever pad is bonded. today it can read the secret that turns a phone into an operator.
app-path-design.md says security over ble rests entirely on the pin being per robot. that is the right place to rest it, and it is why the pin should be readable by exactly the peers allowed to set it. a person reads it the way they set it, with sudo, which system set-pin already requires.
nothing fails today and nothing is known to be exploiting this. it is a secret sitting on the wrong side of a line the daemon draws carefully everywhere else. one line moves it, and the board test is unaffected since its member is in --allow-user. branch coming.
on main at 5984efb.
configdgates every mutating call on the caller's uid and leaves reads open to anyone who can reach the socket, on purpose, so support can inspect a robot it may not change.system.pairingPinis counted as a read. it is not one. the pin is what authenticates a phone over ble, and once a phone holds it every mutating call on that transport is reachable,net.connect,pad.pair,update.apply,account.loginwithforce. so a peer that may read the pin may change the robot by another route, and the gate onsystem.setPairingPinis only as strong as the gate on reading it back, which is none.who can reach the socket is the
robotgroup, and the units put every daemon in it:btd,mediad,padd,tofd.btdneeds the pin, it answers the pairing exchange with it, and it is in--allow-userfor that. the other three have no reason to hold it.paddis the one the repository describes as the process whose whole value is having no privileged access, and it parses input from whatever pad is bonded. today it can read the secret that turns a phone into an operator.app-path-design.mdsays security over ble rests entirely on the pin being per robot. that is the right place to rest it, and it is why the pin should be readable by exactly the peers allowed to set it. a person reads it the way they set it, with sudo, whichsystem set-pinalready requires.nothing fails today and nothing is known to be exploiting this. it is a secret sitting on the wrong side of a line the daemon draws carefully everywhere else. one line moves it, and the board test is unaffected since its
memberis in--allow-user. branch coming.on main at 5984efb.