SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 3:44 UTC (Thu) by slashdot (guest, #22014)
Parent article: SELinuxDenyPtrace and security by default

The problem is not really just ptrace, it's that the Linux permission model is fundamentally broken.

Specifically, there should be a strong distinction between the privileges of a USER, and the privileges of a PROGRAM, which should NOT get all the privileges of the user who runs it (actually, it should get none, by default).

It would be nice if someone finally realized this, and fixed the issue, for example by assigning an uid to each user+program combination like Android does.

Like the article says, users nowadays would really like (and sometimes even expect) to run an arbitrary untrusted program WITHOUT it being able to cause any damage.

This includes not being able to put a trojan in $HOME/.profile, logging keystrokes, destroying your documents, etc; fixing all this requires to change the permission model, not paper over ptrace.

to post comments

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 4:47 UTC (Thu) by dlang (guest, #313) [Link] (9 responses)

people also expect to be able to save a spreadsheet from e-mail and then open it as a spreadsheet (or go the other way)

such a thing would be blocked by the "every app has a different userid" approach

things aren't as simple as you would like them to be.

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 5:36 UTC (Thu) by slashdot (guest, #22014) [Link] (8 responses)

Well, of course you need additional mechanisms to selectively grant programs the ability to access files, preferably with no changes to applications.

For example, your use case can be fixed with no application changes by making the kernel/glibc:
1. Switch to the proper user+program uid combination upon execve
2. Grant access to all paths listed as command line arguments

Likewise, the GTK/Qt open file dialog APIs need to be fixed to communicate with a trusted daemon that actually opens the dialogs and grants permission.

Again, someone with no clue about computers would never guess that the game they just downloaded can trash all their personal files, since it's simply absurd system behavior.

Why this isn't considered a huge security issue is a mystery to me.

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 5:48 UTC (Thu) by dlang (guest, #313) [Link] (7 responses)

and how would you tell the difference between this malicious game and a copy of libreoffice? or a different browser?

how is all this configuration about what applications are allowed to access what programs going to be administered?

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 6:15 UTC (Thu) by slashdot (guest, #22014) [Link] (6 responses)

The copy of LibreOffice has the same permissions of the game: none (i.e. the same as a random uid).

You open files like this:
1. User clicks Open in LibreOffice
2. LibreOffice asks GTK+ to run the Open dialog
3. GTK+ doesn't open the dialog, but instead sends a request via D-Bus to the session file manager
4. The session file manager opens the Open dialog
5. The user selects the file to open
6. The session file manager instructs the kernel LSM to grant access to the user-selected path to LibreOffice
7. The session file manager gives the user-selected path (either as a path, or as an FD over AF_UNIX that becomes /proc/self/fd/#) back to LibreOffice's GTK+ via D-Bus, which then gives it to LibreOffice
8. LibreOffice opens the file

Of course, this also needs a properly designed windows manager that doesn't let random clients simulate keystrokes and other nefarious stuff.

The game can try to do the same, but the user is unlikely to choose his own personal files when asked about which file to open.

Of course, there's a bunch of other scenarios that need to be handled, but it's all fixable with minimal or no changes to applications.

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 7:08 UTC (Thu) by hppnq (guest, #14462) [Link] (4 responses)

9. LibreOffice chokes on the malicious input it read from the file.

You can't base your security model on trusting sources that can't be trusted. But maybe you're just taking the mickey.

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 9:19 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

So what? If Libreoffice is properly sandboxed then it can't access other files and at most can be used to send out spam (if networking is enabled) until Libreoffice process is killed.

Of course, it leaves the problem of local vulnerabilities. But that's another story.

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 9:19 UTC (Thu) by renox (guest, #23785) [Link]

So what? If LibreOffice has no permissions, it cannot do much harm..

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 9:24 UTC (Thu) by slashdot (guest, #22014) [Link] (1 responses)

But it can't do any real damage, because it has no permissions to do so.

Also, with NX and ASLR, it should be next to impossible to actually do anything beyond crashing the application with a single document.

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 16:20 UTC (Thu) by hppnq (guest, #14462) [Link]

It's not extremely difficult to see the problem here: if you can't trust your editor if you need to edit your .profile, or if you can't trust it to properly handle its contents -- a program crash is not necessarily involved -- then what good is it to you that you have a secure way of opening it?

Who or what specifies what is or is not permitted?

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 14:23 UTC (Thu) by dgm (subscriber, #49227) [Link]

9. LibreOffice tries to open a second file linked in the document, or via code macro, fails miserably.
10. User swears, disables the broken security measures and goes back to working as usual.

SELinuxDenyPtrace and security by default

Posted Apr 12, 2012 14:03 UTC (Thu) by mstone (subscriber, #58824) [Link]

As the author of OLPC's circa-2007 "rainbow" uid-based sandboxing system (see http://sandboxing.org), uid-based sandboxing works reasonably well at the level of the kernel but interacts poorly with current free software desktops and is only questionably useful against adaptive adversaries given the rate at which new local privilege escalation attacks are discovered.

SELinuxDenyPtrace and security by default

Posted Apr 13, 2012 6:08 UTC (Fri) by jackb (guest, #41909) [Link]

Specifically, there should be a strong distinction between the privileges of a USER, and the privileges of a PROGRAM, which should NOT get all the privileges of the user who runs it (actually, it should get none, by default).

Isn't that what selinux is all about?