4 ms·

UAC in practice doesn't function as a security boundary, and to make it one would so inconvenience users that they'd just go to other OSes. Both UAC and sudo a

UAC in practice doesn't function as a security boundary, and to make it one would so inconvenience users that they'd just go to other OSes. Both UAC and sudo are just OS level cookie dialog boxes. Let's get rid of all three. We need to give up on the UAC/sudo/etc. style of user based privilege escalation and instead sandbox apps, not users, just like Android and iOS do.

BSDobelix 2y ago
>sandbox apps This is about drivers...
- quotemstr 2y ago
  1) drivers should be apps too (Redox and others (even macOS partially) get this right) 2) driver vulnerabilities are there regardless of user setup. Making a user click a UAC button doesn't make the vulnerability disappear
  - cruffle_duffle 2y ago
    Drivers can be whatever but their effect is usually global not for a specific user or app. So when you update, say, a graphics driver you are updating a shared resource used by everything in the system. You can run that display driver in whatever security context you want be it “root” or its own constrained context but that doesn’t change the fact that other things in the system, running under their own security contexts, are feeding that driver stuff. And given there is generally only one display output, or sound output, or whatever, all things in the system have to use it for output, making it more privileged than the rest. Whatever security context a display driver runs in, that context by requirement has to be more privileged than whatever context your browser or a calculator app runs in. To make changes to that shared display driver, you need to cross some kind of security boundary and it would be nice to make sure the user is who they say they are, they are allowed to do the requested action and they are made aware of the change. Thus methods like UAC and sudo. I’m not sure how you can escape that. Removing sudo and UAC doesn’t change the fact that something wants to mess with a shared resource running with some kind of elevated privilege.
    - anthk 2y ago
      Check Hurd's daemons and Plan9/9front (and Hurd's) namespaces.
      - deleted 2y ago
        [deleted]
      - deleted 2y ago
        [deleted]
    - ruthmarx 2y ago
      > Thus methods like UAC and sudo. UAC and Sudo are pretty different when you actually compare their implementations and not just purpose. Sudo is just a text prompt, UAC's design includes an entire isolated desktop to ensure fake prompts and such can't happen.
  - gosub100 2y ago
    I used to openly hate the UAC box but now I do recognize it as a low cost, high-return feature that interrupts people to force them to recognize that something serious is about to happen. It probably works fine for families and small businesses where it gives non-technical people and opportunity to back out of whatever they were doing, especially if they didn't realize or intend to change something.
  - BSDobelix 2y ago
    >drivers should be apps too (Redox and others (even macOS partially) get this right) Man i stop here since you don't even know what a driver is, and no, nor Redox or macOS can do anything against a bad/hostile but signed driver. But you obviously don't know what drivers are (hint..communicating directly with hardware)
    - quotemstr 2y ago
      Have you ever heard of an IOMMU? Talking to hardware is not a god mode cheat code. It's long been feasible to limit a drive's access to hardware it's supposed to manage. Why should I let my NVMe driver talk to my NIC? It shouldn't even be able to see plaintext disk sectors! If you're going to make sweeping statements about others being incorrect, it would behoove you to become familiar with the material.
      - BSDobelix 2y ago
        [flagged]
        quotemstr 2y ago
        You're clearly interested in operating systems. I hope you learn about them one day so you can contribute to one. You might want to start with, e.g. infiniband drivers, which somehow allow programs to communicate "directly" with hardware without having unlimited privilege. There's a lot more to OS design than a user/kernel dichotomy, and user mode can do more than you think.
        BSDobelix 2y ago
        >infiniband drivers, which somehow allow programs to communicate "directly" with hardware At least you understand what drivers do, like my printer-driver or GPU-Drivers
        ruthmarx 2y ago
        > Hey i stop here, You should, because it's not a good look for you. You're clearly speaking from ignorance. OS research has progressed a lot from what you learned 20 years ago or whatever.
tsujamin 2y ago
> Both UAC and sudo are just OS level cookie dialog boxes To be fair, that's misconstruing UAC and CredUI/Secure Desktop a little. There probably is merit in switching to an isolated desktop session when seeking consent, or user credentials, despite the fact that UAC/the AuthZ part within a user account has flaws. I think another issue is probably that most user's exposure to UAC is on machine's they're the sole user and administrator of; it's a different ballgame in enterprises where the end user is probably the least privileged principal logged into a particular PC. Windows et al have Sandboxed apps, but which apps and which users should be allowed to do system-level confirmation type changes? iOS and Android are (for the most part) on single user devices, you still need some sort of AuthZ system to decide who and which apps can change what on multi-user systems.
yndoendo 2y ago
I don't understand why moving to system designs that require exploitation of the accessibility layer to turn a device into something semi functional. Those OS go out of the way preventing features that hinder usefulness of the devices. Such as recording phone calls. Allowing the blocking of network IP addresses and domains. While supplying monolithic integration that is limited to all but the OS maintainers. Google dialer does not allow for integration of 3rd party contacts. It is built around Google remote storage. Apple Messenger doesn't allow for conversing with non Apple device users except for insecure text messaging while promoting cyber bullying with green vs blue text. Another security and business risk of using Google or Apple for content storage with limited recourse when they lock out our accounts.
- kaoD 2y ago
  There's a middle ground where apps are sandboxed but you're still in full control... But of course OS vendors will not allow that, so we're just daydreaming here.
- miki123211 2y ago
  > We need to give up on the UAC/sudo/etc. style of user based privilege escalation and instead sandbox apps, not users, just like Android and iOS do. > Those OS go out of the way preventing features that hinder usefulness of the devices. But one isn't necessarily synonymous with the other. Mac OS is slowly going in this direction. Their policy these days is that apps shouldn't be able to do dangerous things by default, but should have the ability to ask for any specific privilege, if and when they need it. Instead of getting a generic "this app wants admin privileges" popup, you get a "this app wants access to the files in your Documents folder" popup. This makes a lot more sense, lets you deny specific permissions while allowing others, and actually tells the user what the app needs the privileges for. The more dangerous the privilege, the more involved the setup process is. The most dangerous privilege of all, that of installing your own kernel extensions, which can do (almost) everything and are your final option when there's truly no API for what you need to do, is gated behind a reboot into recovery mode. This is combined with new, more secure APIs, so that privilege escalation is often entirely unnecessary. For example, most things that were formerly accomplished via kernel drivers can now be done with sandboxed, userspace processes, and there are APIs like the photo picker, where the user picks what photos to share in a system-managed window, that require no extra privilege because the system knows that the user just clicked on a photo in the context of that app.
noinsight 2y ago
> UAC in practice UAC is not a security boundary by design. > It’s important to be aware that UAC elevations are conveniences and not security boundaries … - Mark Russinovich, Microsoft Corporation [1] [1] https://web.archive.org/web/20080101143433/http://www.microsoft.com/technet/technetmag/issues/2007/06/UAC/default.aspx https://web.archive.org/web/20080101143433/http://www.micros...

BSDobelix 2y ago

>sandbox apps This is about drivers...

quotemstr 2y ago
1) drivers should be apps too (Redox and others (even macOS partially) get this right) 2) driver vulnerabilities are there regardless of user setup. Making a user click a UAC button doesn't make the vulnerability disappear
- cruffle_duffle 2y ago
  Drivers can be whatever but their effect is usually global not for a specific user or app. So when you update, say, a graphics driver you are updating a shared resource used by everything in the system. You can run that display driver in whatever security context you want be it “root” or its own constrained context but that doesn’t change the fact that other things in the system, running under their own security contexts, are feeding that driver stuff. And given there is generally only one display output, or sound output, or whatever, all things in the system have to use it for output, making it more privileged than the rest. Whatever security context a display driver runs in, that context by requirement has to be more privileged than whatever context your browser or a calculator app runs in. To make changes to that shared display driver, you need to cross some kind of security boundary and it would be nice to make sure the user is who they say they are, they are allowed to do the requested action and they are made aware of the change. Thus methods like UAC and sudo. I’m not sure how you can escape that. Removing sudo and UAC doesn’t change the fact that something wants to mess with a shared resource running with some kind of elevated privilege.
  - anthk 2y ago
    Check Hurd's daemons and Plan9/9front (and Hurd's) namespaces.
    - deleted 2y ago
      [deleted]
    - deleted 2y ago
      [deleted]
  - ruthmarx 2y ago
    > Thus methods like UAC and sudo. UAC and Sudo are pretty different when you actually compare their implementations and not just purpose. Sudo is just a text prompt, UAC's design includes an entire isolated desktop to ensure fake prompts and such can't happen.
- gosub100 2y ago
  I used to openly hate the UAC box but now I do recognize it as a low cost, high-return feature that interrupts people to force them to recognize that something serious is about to happen. It probably works fine for families and small businesses where it gives non-technical people and opportunity to back out of whatever they were doing, especially if they didn't realize or intend to change something.
- BSDobelix 2y ago
  >drivers should be apps too (Redox and others (even macOS partially) get this right) Man i stop here since you don't even know what a driver is, and no, nor Redox or macOS can do anything against a bad/hostile but signed driver. But you obviously don't know what drivers are (hint..communicating directly with hardware)
  - quotemstr 2y ago
    Have you ever heard of an IOMMU? Talking to hardware is not a god mode cheat code. It's long been feasible to limit a drive's access to hardware it's supposed to manage. Why should I let my NVMe driver talk to my NIC? It shouldn't even be able to see plaintext disk sectors! If you're going to make sweeping statements about others being incorrect, it would behoove you to become familiar with the material.
    - BSDobelix 2y ago
      [flagged]
      - quotemstr 2y ago
        You're clearly interested in operating systems. I hope you learn about them one day so you can contribute to one. You might want to start with, e.g. infiniband drivers, which somehow allow programs to communicate "directly" with hardware without having unlimited privilege. There's a lot more to OS design than a user/kernel dichotomy, and user mode can do more than you think.
        BSDobelix 2y ago
        >infiniband drivers, which somehow allow programs to communicate "directly" with hardware At least you understand what drivers do, like my printer-driver or GPU-Drivers
      - ruthmarx 2y ago
        > Hey i stop here, You should, because it's not a good look for you. You're clearly speaking from ignorance. OS research has progressed a lot from what you learned 20 years ago or whatever.

tsujamin 2y ago

> Both UAC and sudo are just OS level cookie dialog boxes To be fair, that's misconstruing UAC and CredUI/Secure Desktop a little. There probably is merit in switching to an isolated desktop session when seeking consent, or user credentials, despite the fact that UAC/the AuthZ part within a user account has flaws. I think another issue is probably that most user's exposure to UAC is on machine's they're the sole user and administrator of; it's a different ballgame in enterprises where the end user is probably the least privileged principal logged into a particular PC. Windows et al have Sandboxed apps, but which apps and which users should be allowed to do system-level confirmation type changes? iOS and Android are (for the most part) on single user devices, you still need some sort of AuthZ system to decide who and which apps can change what on multi-user systems.

yndoendo 2y ago

I don't understand why moving to system designs that require exploitation of the accessibility layer to turn a device into something semi functional. Those OS go out of the way preventing features that hinder usefulness of the devices. Such as recording phone calls. Allowing the blocking of network IP addresses and domains. While supplying monolithic integration that is limited to all but the OS maintainers. Google dialer does not allow for integration of 3rd party contacts. It is built around Google remote storage. Apple Messenger doesn't allow for conversing with non Apple device users except for insecure text messaging while promoting cyber bullying with green vs blue text. Another security and business risk of using Google or Apple for content storage with limited recourse when they lock out our accounts.

kaoD 2y ago
There's a middle ground where apps are sandboxed but you're still in full control... But of course OS vendors will not allow that, so we're just daydreaming here.
miki123211 2y ago
> We need to give up on the UAC/sudo/etc. style of user based privilege escalation and instead sandbox apps, not users, just like Android and iOS do. > Those OS go out of the way preventing features that hinder usefulness of the devices. But one isn't necessarily synonymous with the other. Mac OS is slowly going in this direction. Their policy these days is that apps shouldn't be able to do dangerous things by default, but should have the ability to ask for any specific privilege, if and when they need it. Instead of getting a generic "this app wants admin privileges" popup, you get a "this app wants access to the files in your Documents folder" popup. This makes a lot more sense, lets you deny specific permissions while allowing others, and actually tells the user what the app needs the privileges for. The more dangerous the privilege, the more involved the setup process is. The most dangerous privilege of all, that of installing your own kernel extensions, which can do (almost) everything and are your final option when there's truly no API for what you need to do, is gated behind a reboot into recovery mode. This is combined with new, more secure APIs, so that privilege escalation is often entirely unnecessary. For example, most things that were formerly accomplished via kernel drivers can now be done with sandboxed, userspace processes, and there are APIs like the photo picker, where the user picks what photos to share in a system-managed window, that require no extra privilege because the system knows that the user just clicked on a photo in the context of that app.

noinsight 2y ago

> UAC in practice UAC is not a security boundary by design. > It’s important to be aware that UAC elevations are conveniences and not security boundaries … - Mark Russinovich, Microsoft Corporation [1] [1] https://web.archive.org/web/20080101143433/http://www.microsoft.com/technet/technetmag/issues/2007/06/UAC/default.aspx https://web.archive.org/web/20080101143433/http://www.micros...