Not logged in
Log in now
Create an account
Subscribe to LWN
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
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)
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.
Posted Apr 12, 2012 5:48 UTC (Thu) by dlang (✭ supporter ✭, #313)
how is all this configuration about what applications are allowed to access what programs going to be administered?
Posted Apr 12, 2012 6:15 UTC (Thu) by slashdot (guest, #22014)
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.
Posted Apr 12, 2012 7:08 UTC (Thu) by hppnq (guest, #14462)
You can't base your security model on trusting sources that can't be trusted. But maybe you're just taking the mickey.
Posted Apr 12, 2012 9:19 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
Of course, it leaves the problem of local vulnerabilities. But that's another story.
Posted Apr 12, 2012 9:19 UTC (Thu) by renox (subscriber, #23785)
Posted Apr 12, 2012 9:24 UTC (Thu) by slashdot (guest, #22014)
Also, with NX and ASLR, it should be next to impossible to actually do anything beyond crashing the application with a single document.
Posted Apr 12, 2012 16:20 UTC (Thu) by hppnq (guest, #14462)
Who or what specifies what is or is not permitted?
Posted Apr 12, 2012 14:23 UTC (Thu) by dgm (subscriber, #49227)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds