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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <662972bd69700_1b61b92949@willemb.c.googlers.com.notmuch>
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ