• Off Topic

  • Is it a bad idea from security point of view to enable CONFIG_BLK_DEV_SR?

I'm considering an option to use external usb devices under Termux (like scanners, etc).
Is there any reason why it's a bad idea from security point of view to enable CONFIG_BLK_DEV_SR for GOS?

    15 days later
    a month later

    mmobder Perhaps you could delineate specifically how you intend to enable this? Knowing the method might be relevant in order to construct an answer.

        fid02 by compiling kernel having CONFIG_BLK_DEV_SR=Y and CONFIG_CHR_DEV_SG=Y
        I believe, as RPi is also on the same arch, there should be respective code to support external Blu-ray and DVD recorders

        • de0u replied to this.

            mmobder I believe, as RPi is also on the same arch, there should be respective code to support external Blu-ray and DVD recorders

            I'm not following. Processor instruction set has very little to do with I/O architecture.

            mmobder compiling kernel having CONFIG_BLK_DEV_SR=Y and CONFIG_CHR_DEV_SG=Y

            Is the question about what might happen if somebody built a private fork of GrapheneOS with support for SCSI devices, or a request for the GrapheneOS team to do that? That does not seem clear in the original post, which might be related to a lack of replies.

            Adding a bunch of large complicated device drivers inherently adds attack surface. For desktop and laptop machines there is often less concern about protection from adversaries with physical access than for phones.

                  de0u or a request for the GrapheneOS team to do that

                  de0u That does not seem clear in the original post

                  in general, that's a reasonable claim, but in the context of GOS, expectation that the team will consider such a request is so low, that only the private fork makes sense.
                  Yes, it's about a private fork.

                  It's about whenever:

                  1. it's possible to claim that GOS is built in a way that enabling SCSI module/infra (if it's robust by itself) shouldn't pose significant risks
                  2. enabling scsi module/drivers in general are not that different from enabling USB

                  The context is - possibility to connect external USB Pioneer DVD and/or Blu-ray recorder to Pixel and backup data to m-discs (provided that there is a respective software package ported to Termux).
                  I use USB scanner attached to my smartphone on a remote VM via usb2ip solution, and it works fine (VM has the scanner drivers etc).
                  But, obviously, it will not work with burning dvds/blu-rays over network.

                  • de0u replied to this.

                        mmobder It's about whenever:

                        1. it's possible to claim that GOS is built in a way that enabling SCSI module/infra (if it's robust by itself) shouldn't pose significant risks
                        2. enabling scsi module/drivers in general are not that different from enabling USB

                        I don't think it's possible for people here to issue assurances along those lines. Adding device drivers that run on top of USB is definitely different from merely enabling USB transport, because there's a lot more code. Adding device drivers of any kind to the GrapheneOS kernel poses risks if those device drivers are risky.

                        GrapheneOS does do some kernel hardening, but it balances safety and performance, and I don't think there's anything structural related to device drivers such as running each one in a VM. So I suspect that if you received an answer from a GrapheneOS developer it wouldn't be, on the one hand, that there is a known specific risk to including SCSI CD-ROM drivers in GrapheneOS or, on the other hand, that it would probably be fine to do that without auditing the large body of code. I suspect it would take a lot of effort for somebody to estimate the risk, and I suspect nobody has done that work.

                        If vulnerabilities are found in the Linux floppy disc driver in 2018 (CVE-2018-7755), 2019 (CVE-2019-14283), 2021 (CVE-2021-20261), and 2022 (CVE-2022-1652), it seems plausible that the sr/sg drivers might contain vulnerabilities too.