netdev - RE: [PATCH main 1/1] macsec: Fix Macsec replay protection

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <IA1PR12MB635369F750521C87790D328AABFF9@IA1PR12MB6353.namprd12.prod.outlook.com>
Date:   Tue, 10 Jan 2023 11:23:26 +0000
From:   Emeel Hakim <ehakim@...dia.com>
To:     Sabrina Dubroca <sd@...asysnail.net>
CC:     "dsahern@...nel.org" <dsahern@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Raed Salem <raeds@...dia.com>
Subject: RE: [PATCH main 1/1] macsec: Fix Macsec replay protection



> -----Original Message-----
> From: Sabrina Dubroca <sd@...asysnail.net>
> Sent: Tuesday, 10 January 2023 12:02
> To: Emeel Hakim <ehakim@...dia.com>
> Cc: dsahern@...nel.org; netdev@...r.kernel.org; Raed Salem
> <raeds@...dia.com>
> Subject: Re: [PATCH main 1/1] macsec: Fix Macsec replay protection
> 
> External email: Use caution opening links or attachments
> 
> 
> 2023-01-10, 10:02:19 +0200, ehakim@...dia.com wrote:
> > @@ -1516,7 +1515,7 @@ static int macsec_parse_opt(struct link_util *lu, int
> argc, char **argv,
> >               addattr_l(n, MACSEC_BUFLEN, IFLA_MACSEC_ICV_LEN,
> >                         &cipher.icv_len, sizeof(cipher.icv_len));
> >
> > -     if (replay_protect != -1) {
> > +     if (replay_protect) {
> 
> This will silently break disabling replay protection on an existing device. This:
>

Thanks for catching that.

>     ip link set macsec0 type macsec replay off
> 
> would now appear to succeed but will not do anything. That's why I used an int with
> -1 in iproute, and a U8 netlink attribute rather a flag.
> 
> I think this would be a better fix:
> 
>         if (replay_protect != -1) {
> -               addattr32(n, MACSEC_BUFLEN, IFLA_MACSEC_WINDOW, window);
> +               if (replay_protect)
> +                       addattr32(n, MACSEC_BUFLEN, IFLA_MACSEC_WINDOW,
> + window);
>                 addattr8(n, MACSEC_BUFLEN, IFLA_MACSEC_REPLAY_PROTECT,
>                          replay_protect);
>         }
> 
> Does that work for all your test cases?

The main test case works however I wonder if it should be allowed to pass a window with replay off
for example:
ip link set macsec0 type macsec replay off window 32 

because now this will silently ignore the window attribute

a possible scenario:
we start with a macsec device with replay enabled and window set to 64
now we perform:
ip link set macsec0 type macsec replay off window 32
ip link set macsec0 type macsec replay on

we expect to move to a 32-bit window but we silently failed to do so.

what do you think?

> 
> >               addattr32(n, MACSEC_BUFLEN, IFLA_MACSEC_WINDOW, window);
> >               addattr8(n, MACSEC_BUFLEN, IFLA_MACSEC_REPLAY_PROTECT,
> >                        replay_protect);
> 
> --
> Sabrina