Hooray for encrypted home directories



  • I think on Windows only domain admins can do it by use GPO to instruct storing the encryption key in AD infrastructure. Local admins cannot do it because it also uses the password as encryption key. (If local admin resets password to an account with EFS/BitLocker encrypted folder, unless account recovery disk is previously created or the user switched back to the previously used password, the data in encrypted folder is lost)



  • @quijibo said:

    No. If you are an administrator (root) on a system... even a Windows system... you have access to everything.
    Ever heard of SELinux?



  • This post is deleted!

  • Discourse touched me in a no-no place

    @quijibo said:

    The only mechanism that should be safe is a removable hardware module (like a smart card) that never shares its private key with software, and does the decryption directly. This way no part of software knows your key, and therefore no one can copy it without having your hardware device.

    Even that's not entirely safe, as the data has to be decrypted to be used (excluding the very small set of algorithms that can work on encrypted data). Perfect safety only comes with perfect unusability. 😃

    @wft said:

    Ever heard of SELinux?

    Same problem. If an evil driver is loaded, you're stuffed. An operating system kernel literally cannot protect things from itself.

    Another strong (but not perfect) approach is to use an encrypted network filesystem (e.g., AFS, or NFS with the right options). With that, the server can be locked down damn hard and can enforce some really strong ACLs: we use this approach with our production webservers, and that means that root on those systems really can't access your files. It's still vulnerable to a bad driver, but even that wouldn't grant very much: the files would remain non-writable (because that server farm can't write to the networked filesystems, as there's a network lockdown enforced by the AFS system) and can't open sockets to the outside world (well duh!) and can't actually do much mischief at all. The system isn't perfect, but it's not vulnerable to the PHP fuck-up of the hour…



  • SELinux does not stop a root user from disabling it.



  • @dkf said:

    Even that's not entirely safe, as the data has to be decrypted to be used (excluding the very small set of algorithms that can work on encrypted data). Perfect safety only comes with perfect unusability.

    Very true. I was thinking that files that you don't access very often are more safe... until next time you decrypt them to use them.



  • @Buddy said:

    It's Ubuntu, so every users gonna be in wheel by default right?

    Did every user bust a deal?



  • Do we need to take this to the obscure references thread (I've never watched mad max)?

    Wheel is the user group that enables privilege elevation with sudo, Linux's strictly worse version of uac. For a long time, the default setting for sudo was to have the protection it offers disabled 80% of the time, because the only way for Linux to be confident that an action was user-initiated is to require a password, and nobody wants to type their password every single time they need to elevate.



  • wrong! wheel groups gives access to 'su' command, sudo group gives user access to sudo.


  • Java Dev

    I don't recall the details, but I know it's actually down to configuration (/etc/sudoers). I do seem to recall ubuntu doesn't have a wheel group, even though the sudoers comments refer to it.



  • probably ubuntu does it "their way". all the normal distros use wheel for su and sudo for sudo. no idea though, I don't use ubuntu


  • Discourse touched me in a no-no place

    @whargarbl said:

    all the normal distros use wheel for su

    Not if they're using the GNU version of su, which doesn't support wheel for “philosophical” reasons. Unless they changed that in the past few years (they might've, now that RMS has stopped doing much coding) that particular fig-leaf of protection isn't there.

    I prefer sudo on the grounds that it lets you much more exactly grant capabilities where necessary (even if that's not it's default configuration). It also has a different idea of when to grant capabilities that isn't so deeply tied to the old skool admin/not-admin distinction.


  • Discourse touched me in a no-no place

    @dkf said:

    Not if they're using the GNU version of su, which doesn't support wheel for “philosophical” reasons.

    Here we see Stallman imposing nonstandard behavior on his version of the su utility — a security tool — for ideological reasons that have nothing to do with security but, in fact, undermine the security the tool can provide. While sudo can always be limited to specific user accounts, the GNU version of su has specifically had the ability to limit its availability to specific users excluded. Incredibly, Stallman seems to want to make it as easy as possible for nonprivileged user accounts to escalate privileges, making the system more subject to brute force attacks and other unauthorized root access than usual.

    Source.



  • Actually, it can prevent setenforce 0, if every label/context that remains in the system is denied permission to disable SELinux. It could, technically, prevent you from mounting /dev/kmem and bit-banging the kernel memory.

    Anyways, if you have one of those exploits, a few android users want to hear about it. Google too.



  • Well, I don't know an admin that's lame enough to shoot their feet by not allowing at least disable it on reboot.

    Servers are not like this Android toys, if you f**ked up the policy setting, it can take you some time to restore it.



  • If all else fails, pull the hard drive, put it in a computer, and boot with a LiveCD. Physical access to the disk is more powerful than root access.



  • It depends. Some servers are located on datacenter and not readily physically accessible.

    On the other hand, you can type "selinux=0" though IPKVMs.



  • @cheong said:

    It depends. Some servers are located on datacenter and not readily physically accessible.

    Nothing a little 48-hour emergency maintenance window can't fix, right?

    Oh, and travel expenses.



  • What's the error code for "server is unplugged"?



  • I think that's ICMP 3-1.


  • Discourse touched me in a no-no place

    @riking said:

    Actually, it can prevent setenforce 0, if every label/context that remains in the system is denied permission to disable SELinux. It could, technically, prevent you from mounting /dev/kmem and bit-banging the kernel memory.

    Once the code is inside the kernel, it's not prevented from being evil. That's pretty much the core of what marks the difference between user and kernel code. The SEL stuff doesn't apply at that level (because that's at the level that's actually in charge of enforcement in the first place) so if something genuinely bad gets in, you're still stuffed. The information leakage happens at a level where it is authorised; everything else is within the model.

    Splitting the kernel so that different pieces can be protected from each other is a thing. That's what microkernels (are supposed to) do.



  • @Buddy said:

    sudo, Linux's strictly worse version of uac

    Them's fightin' words



  • @dkf said:

    the GNU version of su, which doesn't support wheel for “philosophical” reasons

    Current version does, configurable using PAM:

    It isn't turned on by default in Debian, which doesn't come configured with a wheel group by default (though doing so is easy) and I imagine Ubuntu inherits this design.



  • What uac does is it guarantees (or at least it tries to) that when it elevates, that the OK button was clicked by an actual human. Can Linux do that?



  • @Buddy said:

    What uac does is it guarantees (or at least it tries to) that when it elevates, that the OK button was clicked by an actual human. Can Linux do that?

    Desktop Linux does not typically come configured with anything parallel to the Windows secure desktop, though the designs of X and PAM are certainly flexible enough to allow such a thing to be created if there were any demand for it.

    A typical desktop Linux installation offers a user experience around privilege elevation which is comparably convenient to the Windows elevation model, but doesn't rely on mechanisms anywhere near as complex under the hood.

    In general, proof of humanity involves supplying a password rather than a simple mouse click. That's arguably more annoying, but in practice I have not found it so (and I use both Windows and desktop Linux regularly). You can also, if you wish, grant passwordless elevation capability on a program-by-program basis; doing this allows those programs to elevate when they need to without any kind of additional system-enforced interactive permission every time. Programs you'd typically set up that way are the ones polite enough to elevate only in response to an explicit lock/unlock button somewhere in their UI.

    On "or at least it tries to": the point of the Windows secure desktop is to set up an environment for authy things to run in under the SYSTEM account, in such a way that they can't be fed simulated clicks, keypresses or other window messages from stuff running inside a user process on the normal desktop. Which is a good idea as far as it goes; but it has enough implementation holes to make it count, in my mind, as security theatre rather than actual security.

    For a start, there are enough badly behaved applications still out there in 2015 that a significant proportion of the Windows user base has been thoroughly trained just to click that OK button whenever the UAC secure desktop prompt pops up, without any understanding of what they're doing. No amount of technical engineering is ever going to fix what's essentially a social engineering issue.

    For seconds: easily the most common way for malware to end up on a Windows box, in 2015, is for it to be bundled with something else as foistware. That means that the malware's installer will already have made it past the airtight hatchway and had a chance to run fully elevated; which lets it install services running under SYSTEM that it can subsequently use to launch literally anything else without ever causing a UAC prompt.

    And finally, Windows 8, 8.1 and 10 allow any admin account to run anything at all, fully elevated, without a UAC elevation step: admin accounts no longer need elevation in order to create a scheduled task that does run elevated, perhaps immediately.


  • Discourse touched me in a no-no place

    @flabdablet said:

    A typical desktop Linux installation offers a user experience around privilege elevation which is comparably convenient to the Windows elevation model, but doesn't rely on mechanisms anywhere near as complex under the hood.

    Specifically, programs like gksudo allow running a program elevated via mechanisms equivalent to sudo but with graphical querying for the user's authorisation action. The end-user experience is relatively similar to that which you get on Windows with UAC or on OSX with its privilege escalation request system (whose name escapes me right now).

    That said, the real key to making a system secure is not just to have secure mechanisms for privilege escalation, but to also make sure that needing to do so is a rare event so that users do not become habituated to permitting it.



  • @dkf said:

    make sure that needing to do so is a rare event so that users do not become habituated to permitting it

    Making the purpose of elevation perfectly clear (e.g. "Enter your password to perform administrative tasks"), and having that prompt happen immediately as a direct result of a user action like choosing an item from a System menu or clicking an Unlock button in a GUI, is also much better in this regard than the completely unhelpful "Windows needs your permission to continue" - especially when the appearance of that prompt can be delayed until the user finally gets around to clicking on the little shield icon that's been mysteriously throbbing in the task bar for the last minute or two.



  • @flabdablet said:

    In general, proof of humanity involves supplying a password rather than a simple mouse click. That's arguably more annoying, but in practice I have not found it so (and I use both Windows and desktop Linux regularly).

    Is typing your password lots of times actually a good thing? ISTR launching xmacrorec as a user process.

    You can also, if you wish, grant passwordless elevation capability on a program-by-program basis; doing this allows those programs to elevate when they need to without any kind of additional system-enforced interactive permission every time. Programs you'd typically set up that way are the ones polite enough to elevate only in response to an explicit lock/unlock button somewhere in their UI.
    Your also bread to trust them not to launch any executables that are writable by the user.
    On "or at least it tries to": the point of the Windows secure desktop is to set up an environment for authy things to run in under the SYSTEM account, in such a way that they can't be fed simulated clicks, keypresses or other window messages from stuff running inside a user process on the normal desktop. Which is a good idea as far as it goes; but it has enough implementation holes to make it count, in my mind, as security theatre rather than actual security.
    It still has significantly fewer holes than a system that hasn't even been written yet.
    For a start, there are enough badly behaved applications still out there in 2015 that a significant proportion of the Windows user base has been thoroughly trained just to click that OK button whenever the UAC secure desktop prompt pops up, without any understanding of what they're doing. No amount of technical engineering is ever going to fix what's essentially a social engineering issue.
    Ok, but you take any individual and put them on one OS, then the other, the prompts are similar enough that whatever habits they have would be the same on both systems.
    For seconds: easily the most common way for malware to end up on a Windows box, in 2015, is for it to be bundled with something else as foistware. That means that the malware's installer will already have made it past the airtight hatchway and had a chance to run fully elevated; which lets it install services running under SYSTEM that it can subsequently use to launch literally anything else without ever causing a UAC prompt.
    And don't get you started on all the ways Microsoft tries to prevent people from installing whatever they damn well please on their own machines, right?
    And finally, Windows 8, 8.1 and 10 allow any admin account to run anything at all, fully elevated, without a UAC elevation step: you no longer need elevation in order to create a scheduled task that does run elevated, perhaps immediately.
    Is there an existing exploit or proof-of-concept for this? Not sure why they decided to enable that, but it seems like it should be easy enough to revert, if it's a real vulnerability.

  • kills Dumbledore

    @flabdablet said:

    In general, proof of humanity involves supplying a password rather than a simple mouse click

    At home I run as a limited user, which means I have to enter an admin password for UAC


  • Discourse touched me in a no-no place

    @Buddy said:

    Your also bread





  • @Buddy said:

    Is there an existing exploit or proof-of-concept for this? Not sure why they decided to enable that, but it seems like it should be easy enough to revert, if it's a real vulnerability.
    Start reading here. Go on, I'll wait.



  • @Buddy said:

    What uac does is it guarantees (or at least it tries to) that when it elevates, that the OK button was clicked by an actual human. Can Linux do that?

    Write a PAM module that hooks to input devices on a local machine directly and does not rely on a PTY (which can be open with expect and other such).
    If you are running remotely, you're in shit, though.
    If your Windows UAC is displayed over some kind of RDP, you cannot guarantee that an actual human and not software is sending you keystrokes and mouse movements.



  • They won't get anywhere with passwords, either, assuming you don't do something stupid like only use 8-character "line noise" passwords.



  • The problem is that your link is interpreting su as switch to root -- dealing with the system I deal with at work requires me to juggle several ordinary user accounts, and su - <accountname> is very helpful for that, and should not require any more privileges than being able to log into those accounts directly!



  • @flabdablet said:

    For a start, there are enough badly behaved applications still out there in 2015 that a significant proportion of the Windows user base has been thoroughly trained just to click that OK button whenever the UAC secure desktop prompt pops up, without any understanding of what they're doing. No amount of technical engineering is ever going to fix what's essentially a social engineering issue.

    Tt's because people (particularly those who work in computer shop) follows misguided practice to disable UAC once they finished the Windows installation (if you have chance to examine the PC images they used to clone for new PCs, most if not all of them have UAC disabled already). Some IT folks even deployed the setting to disable UAC to GPO so ALL machines inside the company are not protected by it. Not stopping those "badly behaved applications" is not the fault of UAC itself.

    @flabdablet said:

    And finally, Windows 8, 8.1 and 10 allow any admin account to run anything at all, fully elevated, without a UAC elevation step: admin accounts no longer need elevation in order to create a scheduled task that does run elevated, perhaps immediately.

    And for this, I'm sure I've seen my Surface Pro 3 running Win8.1 has shown consent prompt for once yesterday, so I'm sure there is still a need for UAC elevation to do admin stuffs.



  • @cheong said:

    I'm sure there is still a need for UAC elevation to do admin stuffs

    You missed the point of flabdablet's post: while directly executing a task that requires elevation from an admin account still puts up UAC, setting up a scheduled task to execute the exact same task does not require UAC at any point and just runs the task elevated. So it's possible for an admin account to run any task fully elevated without going through UAC, though running it the normal way will still go through UAC.

    My main complaint with the Windows security model is that, as an admin, I want to say "always let limited users run this specific program from this specific shortcut as elevated without having to get me to enter my password every time". (That way my kids can play certain games even when I'm not home, and don't have to bother me to enter my password when I am at home.) The only way I can find to do this is /runas /savecred, which they could apply to run anything elevated at any time. Fortunately they're not interested enough to do this, as far as I can tell, but it's annoying that there seems to be no middle ground. I'd love to have an sudoers-type model where I could say "these accounts can run these specific programs elevated, but not anything else".



  • I found creating task with "run at highest priviledge" and create shortcut for "schtask /run /tn <taskname>" a possible workaround for "running admin process with password prompt" and "allow some application to run with admin right without invoking UAC".

    Something similar to config for sudoers... even if not a perfect replacement.

    You can export the tasks to XML file to deploy to other machines, and copy the shortcuts there as well.



  • @Scarlet_Manuka said:

    My main complaint with the Windows security model is that, as an admin, I want to say "always let limited users run this specific program from this specific shortcut as elevated without having to get me to enter my password every time". (That way my kids can play certain games even when I'm not home, and don't have to bother me to enter my password when I am at home.)

    ... why would a video game need elevation?

    I think you're blaming the wrong party for this "problem".


  • Java Dev

    @blakeyrat said:

    ... why would a video game need elevation?

    This. Stop playing horribly written video games.



  • @PleegWat said:

    Stop playing horribly written video games.

    But @Scarlet_Manuka isn't the one playing them:

    @Scarlet_Manuka said:

    (That way my kids can play certain games even when I'm not home, and don't have to bother me to enter my password when I am at home.)



  • @PleegWat said:

    This. Stop playing horribly written video games.

    Or don't install them into the system program files folder? Self-updating mechanisms are a bit of a drag otherwise...


  • Discourse touched me in a no-no place

    @blakeyrat said:

    why would a video game need elevation?

    Coming from you that seems like just about the biggest rhetorical question ever.



  • @tarunik said:

    Or don't install them into the system program files folder? Self-updating mechanisms are a bit of a drag otherwise...

    This is why Steam alters the permissions of its own folders during install. So... even if you do install it into Program Files, your user has permissions to modify the contents of the steamapps (and probably other) directories.


  • Discourse touched me in a no-no place

    @powerlord said:

    This is why Steam alters the permissions of its own folders during install.

    Snort. "Why fix the problem when we can bandaid it?"



  • @FrostCat said:

    @powerlord said:
    This is why Steam alters the permissions of its own folders during install.

    Snort. "Why fix the problem when we can bandaid it?"

    Changing the permissions of its folder so users can write to it IS the fix.



  • @powerlord said:

    This is why Steam alters the permissions of its own folders during install. So... even if you do install it into Program Files, your user has permissions to modify the contents of the steamapps (and probably other) directories.

    That works too, of course...


  • Discourse touched me in a no-no place

    @powerlord said:

    Changing the permissions of its folder so users can write to it IS the fix.

    No--that's a bandaid. The fix is to put user files in the place you're supposed to put user files.



  • @FrostCat said:

    @powerlord said:
    Changing the permissions of its folder so users can write to it IS the fix.

    No--that's a bandaid. The fix is to put user files in the place you're supposed to put user files.

    Most of the steamapps directory is common to all users these days.


  • Discourse touched me in a no-no place

    @powerlord said:

    Most of the steamapps directory is common to all users these days.

    There's a place for that, too.


Log in to reply