Stock: USB data line control should note it is only possible with an external app

[lucasmz-dev]

This column I think is a bit weird, I don't think stock Android usually has control for this. I certainly don't remember that. LineageOS has some, CalyxOS has some too. I feel like it is better to maybe note that this is not usually available. I suppose the implementation may the same, so using AOSP components, but it is not available anywhere and I think that should be noted.

Calyx has Block all, allow only when unlocked, and never block, and defaults to allow only when unlocked. Lineage is pretty much the same, though it mentions ADB and seems like a different implementation, on Calyx AFAIK, if someone has USB debugging enabled, USB restrictions rules get disabled temporarily, which makes sense.

My view would be that at least Calyx, should have it say "Yes" and stock or any other OS that doesn't implement this say "No" and then maybe Graphene have a greener bar for being a bit more involved with kernel stuff and all.

[matchboxbananasynergy]

"Standard AOSP controls" makes sense here, since those implementations use the upsteam AOSP USB HAL to do the blocking, which doesn't reduce attack surface in the way GrapheneOS' implementation does.

[matchboxbananasynergy]

To further expand on this and to be more specific, the feature in CalyxOS and LineageOS is using the standard Android USB HAL which does not disable USB data lines, rather, it only disables high level USB functionality which Android already mostly supports for USB gadgets as standard functionality, just not for USB peripherals.

This approach does not block new connections once locked, and does not disable USB data lines. This approach waits until the last connection ends and enables the Android USB HAL disable feature, which disables USB peripherals and the off-by-default gadget support, but not USB data lines, and not USB alt modes (such as DisplayPort).

[lucasmz-dev]

That's valid, I think it's worth it to have a better view even with that, Stock android doesn't really have any actual exposed controls (well, not usually anyway) and so this column ATM so it might confuse the user into thinking somehow stock has any even if not great controls, or that the other ones don't have any, that's kind of unfair.

[matchboxbananasynergy]

It's usable in stock OS by using e.g. https://github.com/x13a/Sentry. "Standard AOSP controls" is there because what's being used is the device admin API implementation of this, so apps can create arbitrary policies for it.

The above example (Sentry) provides 1) always disabled, or 2) disabled when locked.

It doesn't actually disable USB data lines despite the docs making it sounds like that, it isn't actually what it means. It disables high level USB peripherals/gadgets. The USB-C protocol, USB protocol, etc. continue working.

That row about disabling USB data is not about that, it's about disabling the USB-C/USB protocols. It doesn't really make sense to add a row for what is a standard Android feature.

It's an option in LineageOS/CalyxOS but they don't actually disable anything when the screen is locked, they continue allowing new USB connections until the last one ends, which means if you have USB headphones attached then someone can attach any USB device once it's locked if they have some cheap tools to do that.

Edit: changed order of paragraphs to make it clear that this is true of the USB HAL used anywhere, not just in CalyxOS, LineageOS etc.

[lucasmz-dev]

When you say "LineageOS/CalyxOS" don't disable anything until the connection is closed when the screen is locked", how does it differ from your guys' GrapheneOS? Do you close a connection when the screen is locked? I found the wording to be a bit confusing here.

[matchboxbananasynergy]

For GrapheneOS' feature in the default mode of disabling it when locked, new USB connections (gadgets, peripherals or alternate modes) are immediately disabled when the screen is locked, and then when existing USB connections end, it actually disables the data lines at the USB controller level.

The standard Android functionality disables new gadgets + peripherals and ends connections to existing ones, but does not disable USB alt modes or USB data, it continues supporting USB-C data and USB data but the kernel won't accept peripherals or use gadget modes.

CalyxOS/LineageOS take the standard functionality and delay activating it until there are no USB connections, so they continue permitting new ones until they activate the standard functionality, which then blocks new connections but doesn't disable USB-C / USB. I'm mentioning USB-C and USB separately because USB is layered on top of USB-C. USB-C is very complex. With the standard Android feature, all of that remains active, it's just disabled at a high level.

The standard functionality disables USB at a high level in the kernel, not the kernel USB-C (lower-level) or the firmware/hardware USB. That means that you should still be able to connect a DisplayPort cable and mirror screen when disabling USB with the standard approach, as an example, since that's USB-C but not really USB, and it disables high level USB connections but leaves the lower level stuff.

Another difference here is that GrapheneOS' feature also supports fully disabling USB (the Off mode), not just data, which also results in turning off support for USB-PD and basic charging to further reduce attack surface for people with higher threat models.

[lucasmz-dev]

At the end of the day, it makes sense to just set stock Android to red with a "only with external tools" text or similar. Needing an external app isn't the same as having it integrated with the OS, it's also something the user needs to figure out, and isn't the default.

[matchboxbananasynergy]

The fundamental capability in both the Stock OS and something like Calyx OS is using the USB HAL, though. There is no ability to disable the USB/USB-C. That's where your misunderstanding stems from, I think.

As an OS, the infrastructure with regards to this is the same as stock, CalyxOS (and I believe LineageOS, DivestOS etc.) just surface those standard AOSP controls.

Given the context of what the row is conveying, I think that a difference between CalyxOS and Stock OS doesn't make sense, since they both use the same thing.

[lucasmz-dev]

I understand that the implementation is different and that GrapheneOS has a more involved implementation, which is very much pointing out. But on stock, using this feels hacky and not planned.

The only thing I'm asking here now is that stock in specific (since the other OSes I believe all have these controls exposed) has a comment on how this is only possible with external tools (e.g. Sentry).

This way the difference in implementation for the more secure GrapheneOS one is very much visible, but stock isn't marked as 'Ok'.

[matchboxbananasynergy]

I think the point I'm making here is being misunderstood, apologies if I'm not phrasing correctly, but my last reply doesn't mention GrapheneOS or its implementation of the feature.

The row in question that has to do with data line control is meant to delineate how each OS deals with this. CalyxOS has the same capability as Stock OS in that regard, since CalyxOS etc. has chosen to adopt the upstream approach via the device admin USB HAL feature. App required or not, the capability (which is what I'm interpreting the row to be about) is the same, right?

Also, the USB HAL feature is meant to be a device admin feature, despite its implementation being subpar, so it makes sense that on stock, you need a device admin app to trigger it. On CalyxOS, if you used a device admin app (such as a work-issued MDM app), enforcement of that same feature could be done through the app as well, assuming nothing is broken in that regard by exposing it elsewhere.

Sentry (and many other apps that utilize the USB HAL for this) work fine. I'm not seeing the difference here.

At the end of the day, Eylenburg should be the one to decide how to approach this, but I think that given the context of the row which describes the fundamental capability to do data line control, of which CalyxOS and Stock etc. have the same, differentiating between the two doesn't make a lot of sense.

As a more general comment on this discussion, GrapheneOS now has updated its documentation due to recents improvements to this feature, and as part of that also explains the differences between this approach and the standard approach, for those who are interested/want more context:

https://grapheneos.org/features#usb-c-port-and-pogo-pins-control

[eylenburg]

At the end of the day, it makes sense to just set stock Android to red with a "only with external tools" text or similar. Needing an external app isn't the same as having it integrated with the OS, it's also something the user needs to figure out, and isn't the default.

I think that's a fair point. Maybe a way to show is to have stock in light red colour (possible but needs an app), Calyx in light green (as it's a real "feature" of the OS but ultimately just leverages the hidden abilities of stock Android), and Graphene in normal green as it adds additional features.

[eylenburg]

@lucasmz-dev do you know if LineageOS is doing the same as CalyxOS? And if so, this should be applicable to /e/ and Iode as well?

[matchboxbananasynergy]

I think that's a fair point. Maybe a way to show is to have stock in light red colour (possible but needs an app), Calyx in light green (as it's a real "feature" of the OS but ultimately just leverages the hidden abilities of stock Android), and Graphene in normal green as it adds additional features.

A few things to consider:

If an app is using the USB HAL, it could be providing more options than the OS feature, so there may be valid use cases in which that makes sense regardless.

I also wanted to make this clear regarding GrapheneOS, the USB-C port and pogo pins feature isn't leveraging the USB HAL thing at all. It's an entirely different approach, which is how it provides what it does.

I would like to avoid people being confused and thinking that e.g. CalyxOS provides something that someone can't have on Stock OS, if that makes sense.

[matchboxbananasynergy]

The proposal at https://github.com/eylenburg/eylenburg.github.io/issues/60 is more comprehensive and should resolve the concern brought up here and make the table accurate again.

[lucasmz-dev]

I won't get into any further discussion on here; I only really wanted to raise a few things that caused a ??? in my mind as an user when looking at the comparasion hosted by eylenburg, and this is getting out of the point where I can say much more and I need to focus on a few things; so I'll unsubscribe from this

Anyways, have a nice one ^^ https://www.youtube.com/watch?v=xaPNR-_Cfn0

[eylenburg]

Thank you all for this really interesting discussion. I definitely learned a few new things. I will implement #60 in the next few days

[matchboxbananasynergy]

I won't get into any further discussion on here; I only really wanted to raise a few things that caused a ??? in my mind as an user when looking at the comparasion hosted by eylenburg, and this is getting out of the point where I can say much more and I need to focus on a few things; so I'll unsubscribe from this

Anyways, have a nice one ^^ https://www.youtube.com/watch?v=xaPNR-_Cfn0

Appreciate the discussion, thanks for taking the time!