4 ms·

Okay, but it's very easy for you to build and sign your own builds that provide root access to the user. I dint understand why you insist on this massive risk

Okay, but it's very easy for you to build and sign your own builds that provide root access to the user. I dint understand why you insist on this massive risk to be laid on on everyone. GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding.

jampekka 1y ago
If the risks are so immense, surely we shouldn't be allowed root on our laptops either?
- bornfreddy 1y ago
  Pssst, quiet, don't give them any ideas... :-/
- paulhart 1y ago
  That's a Chromebook, no?
  - jampekka 1y ago
    Chromebooks have Developer Mode that gives full root. https://www.chromium.org/chromium-os/developer-library/guides/device/developer-mode/ https://www.chromium.org/chromium-os/developer-library/guide...
- ajjahs 1y ago
  [dead]
- codethief 1y ago
  From a security point of view that would be a good idea, or at least making sure you don't need root for everyday tasks. Requiring root to, e.g., install & configure applications is a huge antipattern IMO.
  - jampekka 1y ago
    Android of course requires root for installing and configuring applications. It just grants the root automatically.
    - oneshtein 1y ago
      Developers cannot trust a random phone «owner».
    - strcat 1y ago
      No, it doesn't. Only a few very core system processes run as root and even those are contained quite a bit via SELinux. The application layer of the OS including installing apps does not run as root or with equivalent access.
  - fsflover 1y ago
    Have a look at https://qubes-os.org https://qubes-os.org to understand why you're mistaken.
    - codethief 1y ago
      I know Qubes. I meant "requiring root to, e.g., install & configure applications is a huge antipattern" on standard Linux distributions, where most people just use sudo in their usual shell, so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root.
      - fsflover 1y ago
        > so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root So if I don't use sudo then the problem with root is solved?
- subscribed 1y ago
  And there's reason why normal windows / Linux laptops are less secure. Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it? And that's even without having access to root (imagine if someone had written a malware like Heartbleed or Shellshock, which then could quietly persist, patch your firmware, or actually do anything it wants?) I hope you're at least running your laptop with selinux in enforcing mode :)
  - jampekka 1y ago
    I'm willing to take the very slight chance of getting compromised in exchange for getting things done.
  - yellowapple 1y ago
    > Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it? The availability of application sandboxen and the availability of root access are two entirely separate security concerns.
    - yupyupyups 1y ago
      Someone can correct me if I'm wrong. If the GUI stack is vulnerable, then those sandboxes could be broken out of. The idea behind not allowing an app to access root is to remove the attack surface introduced by the GUI stack. An alternative interface to a GUI would be some physical connection (like usb-c). So accessing root exclusively via a console port or USB would be safer in theory. This is true regardless if it's a phone or a PC. Desktops are unfortunately waaaay behind something like GrapheneOS or iOS in terms of sandboxing. The closest in the desktop world is Qubes OS, but that's not a realistic alternative to normal OSes for the common user.
      - jampekka 1y ago
        Running GUI programs as root has been discouraged more or less always. Nowadays GUI programs that need root request it, via e.g. PolicyKit, for the specific operations it is needed. I very much don't want to have some external device to have root access to my computer. If iOS type sandboxing where I can't access most of the data at all is ahead, I'm glad to be behind.
sfdlkj3jk342a 1y ago
They actually do include how to do it in their official build guide. Just change the build target from -user to -userdebug. All other steps remain the same. That will give you adb root access.
- yjftsjthsd-h 1y ago
  > That will give you adb root access. I don't want adb root access? I want to be able to run apps with root access.
fsflover 1y ago
> massive risk Are you saying that the Qubes OS security model is worse than the GrapheneOS one?
- IlikeKitties 1y ago
  It's a different approach to compartmentalization and the security risk of root in Grapheneos is different to that in QubesOS. But you know this looking at your bio, you just chose to ignore it.
  - fsflover 1y ago
    Can you elaborate on the differences in the compartmentalization? When the existence of root is equivalent to a broken security, it doesn't look secure to me at all. Are you talking about the security from the user? By the way, personal attacks are against the HN Guidelines.
    - IlikeKitties 1y ago
      Ah yes thats a real good faith argument you got there. GrapheneOS is designed so you don’t need root to run apps or manage the device. Compartmentalization is on an per app level. And you already know how qubes does compartmentalisation.
      - strcat 1y ago
        Sandboxing is on a per-app level but those sandboxed apps can be hooked up to different profiles. The Linux kernel is the main weakness of the current app sandboxing along with system services to a lesser extent. Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on. There's already hardware-based virtualization integration but it really needs native GPU virtualization support to be fully usable for GUI usage without relying on proxying GPU commands to the host OS. Pixel 10 is the first device with this, but it will take us some time to support the 10th gen Pixels and our focus is going to be more on Snapdragon devices and their Gunyah hypervisor soon due to our OEM partnership.
yjftsjthsd-h 1y ago
> Okay, but it's very easy for you to build and sign your own builds that provide root access to the user. > GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding. It really sounds like you call it very easy, then promptly turn around and say that it's not easy but that's okay because it should be hard. You're also conflating the ability to assess security risks with the ability to build Android from source and modify it in the process, even though these skills are mostly unrelated. > I dint understand why you insist on this massive risk to be laid on on everyone. Largely, I don't agree that it's a "massive risk" in the first place. I don't believe that user-controlled root access is a problem, and I certainly don't believe that a default-off option to enable root access constitutes a problem.
- subscribed 1y ago
  No, it is very easy. You either build a debug image, so you just have it, or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it. Use your own keys to sign and you're golden. The assumption is you know what you're doing, and then it's very easy. If you don't, then you likely shouldn't. I am not really "conflating" these in a way you suggest: it's not just about building the image but deeper understanding that will bring both. It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it. And lastly, it's okay if you don't consider it a massive risk. I do. Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-suffer-more-cyberattacks/ https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-protect-your-app-with-root-detection https://www.talsec.app/blog/what-is-rooting-and-how-to-prote... For you it's not a risk, okay, I guess. I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle. You argue from the position of convenience and capabilities. Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.

jampekka 1y ago

If the risks are so immense, surely we shouldn't be allowed root on our laptops either?

bornfreddy 1y ago
Pssst, quiet, don't give them any ideas... :-/
paulhart 1y ago
That's a Chromebook, no?
- jampekka 1y ago
  Chromebooks have Developer Mode that gives full root. https://www.chromium.org/chromium-os/developer-library/guides/device/developer-mode/ https://www.chromium.org/chromium-os/developer-library/guide...
ajjahs 1y ago
[dead]
codethief 1y ago
From a security point of view that would be a good idea, or at least making sure you don't need root for everyday tasks. Requiring root to, e.g., install & configure applications is a huge antipattern IMO.
- jampekka 1y ago
  Android of course requires root for installing and configuring applications. It just grants the root automatically.
  - oneshtein 1y ago
    Developers cannot trust a random phone «owner».
  - strcat 1y ago
    No, it doesn't. Only a few very core system processes run as root and even those are contained quite a bit via SELinux. The application layer of the OS including installing apps does not run as root or with equivalent access.
- fsflover 1y ago
  Have a look at https://qubes-os.org https://qubes-os.org to understand why you're mistaken.
  - codethief 1y ago
    I know Qubes. I meant "requiring root to, e.g., install & configure applications is a huge antipattern" on standard Linux distributions, where most people just use sudo in their usual shell, so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root.
    - fsflover 1y ago
      > so an attacker merely needs to take over a non-root user account (and their .bashrc) to get root So if I don't use sudo then the problem with root is solved?
subscribed 1y ago
And there's reason why normal windows / Linux laptops are less secure. Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it? And that's even without having access to root (imagine if someone had written a malware like Heartbleed or Shellshock, which then could quietly persist, patch your firmware, or actually do anything it wants?) I hope you're at least running your laptop with selinux in enforcing mode :)
- jampekka 1y ago
  I'm willing to take the very slight chance of getting compromised in exchange for getting things done.
- yellowapple 1y ago
  > Look, if your media player or game can just steal your ssh keys, or slightly modify your changes to your code, or inject a script into your startup sequence, that's not very safe, is it? The availability of application sandboxen and the availability of root access are two entirely separate security concerns.
  - yupyupyups 1y ago
    Someone can correct me if I'm wrong. If the GUI stack is vulnerable, then those sandboxes could be broken out of. The idea behind not allowing an app to access root is to remove the attack surface introduced by the GUI stack. An alternative interface to a GUI would be some physical connection (like usb-c). So accessing root exclusively via a console port or USB would be safer in theory. This is true regardless if it's a phone or a PC. Desktops are unfortunately waaaay behind something like GrapheneOS or iOS in terms of sandboxing. The closest in the desktop world is Qubes OS, but that's not a realistic alternative to normal OSes for the common user.
    - jampekka 1y ago
      Running GUI programs as root has been discouraged more or less always. Nowadays GUI programs that need root request it, via e.g. PolicyKit, for the specific operations it is needed. I very much don't want to have some external device to have root access to my computer. If iOS type sandboxing where I can't access most of the data at all is ahead, I'm glad to be behind.

sfdlkj3jk342a 1y ago

They actually do include how to do it in their official build guide. Just change the build target from -user to -userdebug. All other steps remain the same. That will give you adb root access.

yjftsjthsd-h 1y ago
> That will give you adb root access. I don't want adb root access? I want to be able to run apps with root access.

fsflover 1y ago

> massive risk Are you saying that the Qubes OS security model is worse than the GrapheneOS one?

IlikeKitties 1y ago
It's a different approach to compartmentalization and the security risk of root in Grapheneos is different to that in QubesOS. But you know this looking at your bio, you just chose to ignore it.
- fsflover 1y ago
  Can you elaborate on the differences in the compartmentalization? When the existence of root is equivalent to a broken security, it doesn't look secure to me at all. Are you talking about the security from the user? By the way, personal attacks are against the HN Guidelines.
  - IlikeKitties 1y ago
    Ah yes thats a real good faith argument you got there. GrapheneOS is designed so you don’t need root to run apps or manage the device. Compartmentalization is on an per app level. And you already know how qubes does compartmentalisation.
    - strcat 1y ago
      Sandboxing is on a per-app level but those sandboxed apps can be hooked up to different profiles. The Linux kernel is the main weakness of the current app sandboxing along with system services to a lesser extent. Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on. There's already hardware-based virtualization integration but it really needs native GPU virtualization support to be fully usable for GUI usage without relying on proxying GPU commands to the host OS. Pixel 10 is the first device with this, but it will take us some time to support the 10th gen Pixels and our focus is going to be more on Snapdragon devices and their Gunyah hypervisor soon due to our OEM partnership.

yjftsjthsd-h 1y ago

> Okay, but it's very easy for you to build and sign your own builds that provide root access to the user. > GOS publishes pretty detailed documentation. They don't explain step by step how to build an OS with root specifically, instead assuming that the users knowing the immense risks also have the skils they need to achieve it without handholding. It really sounds like you call it very easy, then promptly turn around and say that it's not easy but that's okay because it should be hard. You're also conflating the ability to assess security risks with the ability to build Android from source and modify it in the process, even though these skills are mostly unrelated. > I dint understand why you insist on this massive risk to be laid on on everyone. Largely, I don't agree that it's a "massive risk" in the first place. I don't believe that user-controlled root access is a problem, and I certainly don't believe that a default-off option to enable root access constitutes a problem.

subscribed 1y ago
No, it is very easy. You either build a debug image, so you just have it, or you add your own patches adding this capability (in exactly the same way the project modifies stock aosp), and build it. Use your own keys to sign and you're golden. The assumption is you know what you're doing, and then it's very easy. If you don't, then you likely shouldn't. I am not really "conflating" these in a way you suggest: it's not just about building the image but deeper understanding that will bring both. It's not disconnected from the project, but it's inherently within the project. SURE you can consider these two separate skills, but within the context of "getting the root on the GOS build" it's one. If you don't know how to make it happen, you don't have a skill to safely use it. And lastly, it's okay if you don't consider it a massive risk. I do. Now let's consider the risks of that, - https://cybernews.com/security/rooted-android-ios-devices-suffer-more-cyberattacks/ https://cybernews.com/security/rooted-android-ios-devices-su... - https://www.talsec.app/blog/what-is-rooting-and-how-to-protect-your-app-with-root-detection https://www.talsec.app/blog/what-is-rooting-and-how-to-prote... For you it's not a risk, okay, I guess. I mean, if you're a security researcher with a considerable reputation, you can certainly argue with authority, but I don't see the angle. You argue from the position of convenience and capabilities. Is the risk high? The consensus is that it is. I agree, you don't, I'm okay with it.