From Fedora Project Wiki
< Features
m (add some markup) |
|||
| (11 intermediate revisions by 2 users not shown) | |||
| Line 15: | Line 15: | ||
== Summary == | == Summary == | ||
<!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --> | <!-- A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release. --> | ||
Coordinated patches to kernel and glibc so that (optionally) strerror(EPERM) | Coordinated patches to kernel and glibc so that (optionally) <code>strerror(EPERM)</code> and <code>strerror(EACCES)</code> give useful information on why permission was denied | ||
== Owner == | == Owner == | ||
< | * Name: [[User:dwalsh| Dan Walsh]] | ||
* Name: [[User:dmalcolm| Dave Malcolm]] | * Email: <dwalsh@redhat.com> | ||
* Name: [[User:dmalcolm| Dave Malcolm]] | |||
* Email: <dmalcolm@redhat.com> | * Email: <dmalcolm@redhat.com> | ||
| Line 33: | Line 32: | ||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
Traditionally, if a process attempts a forbidded operation, errno for that thread is set to EACCES or EPERM, and a call to strerror() returns a localized version of "Permission Denied" or "Operation not permitted". This string appears throughout textual UIs. For example, it will show up in command-line tools, in exceptions within scripting languages, etc. | Traditionally, if a process attempts a forbidded operation, errno for that thread is set to EACCES or EPERM, and a call to strerror() returns a localized version of "Permission Denied" or "Operation not permitted". This string appears throughout textual UIs and syslog messages. For example, it will show up in command-line tools, in exceptions within scripting languages, etc. | ||
There are an increasing number of ways in which you can fail to have permission to do something: | There are an increasing number of ways in which you can fail to have permission to do something: | ||
| Line 39: | Line 38: | ||
* Linux security modules (e.g. SELinux mandatory access controls) | * Linux security modules (e.g. SELinux mandatory access controls) | ||
* capabilities | * capabilities | ||
* seccomp | |||
* etc (TODO: expand this list) | * etc (TODO: expand this list) | ||
As we continue to add mechanisms for the Kernel to deny permissions, the Administrator/User is faced with just a message that says "Permission Denied" Then if the administrator is lucky enough or skilled enough to know where to look, he might be able to understand why the process was denied access. | |||
Under normal deployment situations we don't want to leak information to an attacker as to why permission was denied, but under development situations it's useful to know why a failure happens. | Under normal deployment situations we don't want to leak information to an attacker as to why permission was denied, but under development situations it's useful to know why a failure happens. | ||
| Line 45: | Line 47: | ||
We propose to: | We propose to: | ||
* patch the kernel so that it can optionally provide user-space with a "failure cookie" giving additional information beyond the bare ERRNO (handled at the per-thread level, like strerror, iirc) | * patch the kernel so that it can optionally provide user-space with a "failure cookie" giving additional information beyond the bare ERRNO (handled at the per-thread level, like strerror, iirc) | ||
* patch glibc's implementation of strerror (and related calls) so that it can use this "failure cookie" to provide a localized extension to the "Operation not permitted" giving additional details. | * patch glibc's implementation of <code>strerror</code> (and related calls) so that it can use this "failure cookie" to provide a localized extension to the "Operation not permitted" giving additional details. | ||
The failure cookie would only be exposed to user space for processes with a particular bit set (using prctl), so that you have to opt-in to having this information exposed. | The failure cookie would only be exposed to user space for processes with a particular bit set (using prctl), so that you have to opt-in to having this information exposed. | ||
| Line 51: | Line 53: | ||
=== Examples === | === Examples === | ||
* cat: /etc/shadow: Permission denied (POSIX: user "david" not owner "root" or in group "root" and file does not have readable-by-all bit) | * <code>cat: /etc/shadow: Permission denied (POSIX: user "david" not owner "root" or in group "root" and file does not have readable-by-all bit)</code> | ||
* [error] [client ::1] Permission denied (SELinux: context "unconfined_u:system_r:httpd_t:s0" does not have permission to read "system_u:object_r:shadow_t:s0") | * <code>[error] [client ::1] Permission denied (SELinux: context "unconfined_u:system_r:httpd_t:s0" does not have permission to read "system_u:object_r:shadow_t:s0")</code> | ||
* mount: Permission Denied (Capabilities: user "david" does not have CAP_SYS_ADMIN) | * <code>mount: Permission Denied (Capabilities: user "david" does not have CAP_SYS_ADMIN)</code> | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Latest revision as of 18:30, 16 March 2016
Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.
Set a Page Watch
Make sure you click watch on your new page so that you are notified of changes to it by others, including the Feature Wrangler
Make sure you click watch on your new page so that you are notified of changes to it by others, including the Feature Wrangler
All sections of this template are required for review by FESCo. If any sections are empty it will not be reviewed
Friendly EPERM
Summary
Coordinated patches to kernel and glibc so that (optionally) strerror(EPERM) and strerror(EACCES) give useful information on why permission was denied
Owner
- Name: Dan Walsh
- Email: <dwalsh@redhat.com>
- Name: Dave Malcolm
- Email: <dmalcolm@redhat.com>
Current status
- Targeted release: [[Releases/<number> | Fedora <number> ]]
- Last updated: (DATE)
- Percentage of completion: XX%
Detailed Description
Traditionally, if a process attempts a forbidded operation, errno for that thread is set to EACCES or EPERM, and a call to strerror() returns a localized version of "Permission Denied" or "Operation not permitted". This string appears throughout textual UIs and syslog messages. For example, it will show up in command-line tools, in exceptions within scripting languages, etc.
There are an increasing number of ways in which you can fail to have permission to do something:
- classic POSIX discretionary access controls
- Linux security modules (e.g. SELinux mandatory access controls)
- capabilities
- seccomp
- etc (TODO: expand this list)
As we continue to add mechanisms for the Kernel to deny permissions, the Administrator/User is faced with just a message that says "Permission Denied" Then if the administrator is lucky enough or skilled enough to know where to look, he might be able to understand why the process was denied access.
Under normal deployment situations we don't want to leak information to an attacker as to why permission was denied, but under development situations it's useful to know why a failure happens.
We propose to:
- patch the kernel so that it can optionally provide user-space with a "failure cookie" giving additional information beyond the bare ERRNO (handled at the per-thread level, like strerror, iirc)
- patch glibc's implementation of
strerror(and related calls) so that it can use this "failure cookie" to provide a localized extension to the "Operation not permitted" giving additional details.
The failure cookie would only be exposed to user space for processes with a particular bit set (using prctl), so that you have to opt-in to having this information exposed.
Examples
cat: /etc/shadow: Permission denied (POSIX: user "david" not owner "root" or in group "root" and file does not have readable-by-all bit)[error] [client ::1] Permission denied (SELinux: context "unconfined_u:system_r:httpd_t:s0" does not have permission to read "system_u:object_r:shadow_t:s0")mount: Permission Denied (Capabilities: user "david" does not have CAP_SYS_ADMIN)
Benefit to Fedora
This feature should significantly simplify debugging permissions issues in Fedora. For example, rather than seeing "Operation not permitted" error and e.g. blindly trying to disable SELinux, a user can see directly whether or not SELinux was involved.
Scope
This would require getting a new user-space interface into the kernel, with corresponding changes to the insides of glibc. The precise mechanism has not been decided yet - presumably whatever is acceptable to the upstream kernel/glibc maintainers.
How To Test
TODO