| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 24 Apr 2024 16:59:41 -0400 From: Willem de Bruijn <willemdebruijn.kernel@...il.com> To: Jakub Kicinski <kuba@...nel.org>, Willem de Bruijn <willemdebruijn.kernel@...il.com> Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com, shuah@...nel.org, petrm@...dia.com, linux-kselftest@...r.kernel.org Subject: Re: [PATCH net-next v5 0/7] selftests: drv-net: support testing with a remote system Jakub Kicinski wrote: > On Wed, 24 Apr 2024 10:13:41 -0400 Willem de Bruijn wrote: > > > I haven't thought about this part much, TBH. I'm not aware of any > > > scheme used in other tests. > > > IIUC the problem is that we need root locally, and then try to SSH > > > over to remote. But normally the SSH keys belong to the non-root > > > user, so SSH'ing as root is annoying? > > > > Yeah. It requires "PermitRootLogin yes" in your sshd_config and > > installing root keys. > > > > It's not a huge issue, but if we do want to fix it, doing so will be > > easier early rather than when more tests are added with implicit > > dependency on having root. > > You know what, we need a diagram. We currently expect: > > > ------------ ------------- > | | | | > | Local user | ---------->| Remote user | > | | / | | > ------------ / ------------- > / > / > ------------ / ------------- > | >*exec*< | / | | > | Local root |-------------U---------------->| Remote root | > | | ? | | > ------------ ------------- > > > We run locally as root. Putting sudo on all local commands would be > annoying. > > On remote we don't currently explicitly say whether we need root. > The user is basically implicitly controlled by the REMOTE_ARGS > and ssh config. > > REMOTE_ARGS="john@...hine" > > will make us log in as john. But *from* root, so pub key of root needs > to be deployed. > > We can support: > > ------------ ------------- > | | | | > | Local user | ? | Remote user | > | ,--------------------U-------------->| | > ------/-----` \ ------------- > | ?su back to user? \ > | \ > ------------ \ ------------- > | >*exec*< | \ | | > | Local root | `--------->| Remote root | > | | | | > ------------ ------------- > > but it's unclear whether that's all you're asking for, or also: > > ------------ ------------- > | | | | > | Local user | | Remote user | > | ,----------------------------------->->?cond sudo? | > ------/-----` -----|------- > | su back to user | > | | > ------------ -----v------- > | >*exec*< | | | > | Local root | | Remote root | > | | | | > ------------ ------------- > > which would require us to annotate privileged remote commands. For many tests the peer traffic generator/sink will not need to be root. But I already see some counter-examples, such as the PF_PACKET packet generation on the transmitter for checksum receive tests.
Powered by blists - more mailing lists