<p dir="ltr"><br>
Den 28 dec 2014 04:59 skrev "Ray Dillinger" <<a href="mailto:bear@sonic.net">bear@sonic.net</a>>:<br>
><br>
> This is not specifically cryptographic, although an implementation<br>
> of it in a secure file system might be.  Any suggestions about<br>
> what would be a better venue for bringing this up would be<br>
> appreciated.<br>
><br>
> The Unix permissions convention of root:group:user is IMO no<br>
> longer really adequate for the security issues we're facing at<br>
> this point, and should probably be replaced with a convention<br>
> of root:usergroup:user:exegroup:executable.<br>
><br>
> The evolution I propose changes the structure of file permissions<br>
> to keep track of a program/program group having privileges over<br>
> that file, and gives the users access to tools for administering<br>
> the privileges of programs/program groups running under their<br>
> own login.</p>
<p dir="ltr">Capabilities based OS design.</p>
<p dir="ltr">You can find helpful pointers in <a href="https://reddit.com/r/netsec">https://reddit.com/r/netsec</a> and <a href="https://reddit.com/r/capabilities">https://reddit.com/r/capabilities</a> (IIRC). Many capabilities based systems use cryptographic tokens to control access and layers of encryption, such that even an exploit to gain access to memory it shouldn't have won't give it access to either reading privileged plaintext or modifying it. </p>
<p dir="ltr">Android does this to some degree, but not fully. It just isolates apps in sandboxes and then offers a number of standardized channels for communicating with each other, and there's no granular access controls so far for your personal data regarding reading (kitkat introduced restricted write access to the SD card, but not for the internally stored files). </p>
<p dir="ltr">IMHO what should be done is that everything run under a user account should be run in isolated sandboxes, only giving access for communication between sandboxes when both programs agree or the user says so. One of the greater benefits for this is that user level malware can't then tamper with your terminal when you run a command with sudo, so it can't perform privilege escalation by piggybacking legitimate software silently (today the terminal is often unprotected software, there's no way to launch it such that you can protect it from malicious code). </p>
<p dir="ltr">And all software should eventually be redesigned to support running sandboxed, to support communicating mainly via limited channels, and so on. And file access and system privileges and user privileges would have to be requested and assigned individually to the sandboxed software. Inside user accounts, it really should be "sandboxes all the way down", as a configuration screw-up putting malware in control should allow you to access the account in a "safe mode" to reset permissions and clear it malware. There shouldn't simply be "inside app sandboxes" and "outside app sandboxes" within accounts. </p>
<p dir="ltr">A sandboxed version of KDE's workspaces would be even better, this would go much further than Qubes OS. You'd have multiple completely isolated desktops with different configurations, one for work, one for browsing, etc, and software within one wouldn't even know of the other workspaces. Different folders in your account would only be accessible from certain workspaces to even further limit the what malware can do. </p>
<p dir="ltr">Also note that Android's runtime ties apps to their sandboxes sandboxes in a way which allows other apps to verify them by their signature and package name. This means that apps from developers which trust each other can give automatic access to certain functionality in between the apps. An office suite wouldn't need to distribute all apps together, yet they could be allowed access to each other's private data as you can be sure they aren't malicious. Just check that the sandbox you get a request from belongs to program X with the correct signature, and no malicious software can tamper with it (unless program X has an exploit in how it handles inputs, though). </p>