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  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]
Date:   Tue, 8 Sep 2020 05:45:27 -0700
From:   Xie He <xie.he.0141@...il.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Question about dev_validate_header used in af_packet.c

On Tue, Sep 8, 2020 at 4:53 AM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> On Tue, Sep 8, 2020 at 1:04 PM Xie He <xie.he.0141@...il.com> wrote:
> >
> > I was recently looking at some drivers, and I felt that if af_packet.c
> > could help me filter out the invalid RAW frames, I didn't need to
> > check the validity of the frames myself (in the driver when
> > transmitting). But now I guess I still need to check that.
> >
> > I feel this makes the dev_validate_header's variable-length header
> > check not very useful, because drivers need to do this check again
> > (when transmitting) anyway.
> >
> > I was thinking, after I saw dev_validate_header, that we could
> > eventually make it completely take over the responsibility for a
> > driver to validate the header when transmitting RAW frames. But now it
> > seems we would not be able to do this.
>
> Agreed. As is, it is mainly useful to block users who are ns_capable,
> but not capable.
>
> A third option is to move it behind a sysctl (with static_branch). Your
> point is valid that there really is no need for testing of drivers against
> bad packets if the data is validated directly on kernel entry.

I was thinking about this again and it came to me that maybe sometimes
people actually wanted to send invalid frames on wire (for testing the
network device on the other end of the wire)? Having thought about
this possibility I think it might be good to keep the ability for
people to have 2 choices (either having their RAW frames validated, or
not validated) through "capability" or through "sysctl" as you
mentioned. We can keep the default to be not validating the RAW frames
because RAW sockets are already intended for very special use and are
not for normal use.

Powered by blists - more mailing lists