| (5 intermediate revisions by the same user not shown) | |||
| Line 14: | Line 14: | ||
== Current status == | == Current status == | ||
* Targeted release: [Fedora 18] | * Targeted release: [Fedora 18] | ||
* Last updated: | * Last updated: Sep 21 2012 | ||
* Percentage of completion: | * Percentage of completion: 100% | ||
selinux-policy fixes are in Fedora 18. | selinux-policy fixes are in Fedora 18. | ||
systemd-192-1.fc18.x86_64 | |||
selinux-policy-3.11.1-26.fc18.noarch | |||
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --> | <!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. --> | ||
| Line 35: | Line 36: | ||
<!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
SELinux Policy needs to be written to govern which domains are able to control which units, (completed) | SELinux Policy needs to be written to govern which domains are able to control which units, (completed) | ||
Systemd has to be modified to look at the label of the calling process and the label of the unit file that the caller wants to manage, and then ask SELinux whether or not the caller is allowed the access | Systemd has to be modified to look at the label of the calling process and the label of the unit file that the caller wants to manage, and then ask SELinux whether or not the caller is allowed the access. | ||
== How To Test == | == How To Test == | ||
| Line 66: | Line 67: | ||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel feature)? --> | ||
Systemd | Systemd has accepted the patch in a release that is in F18. | ||
== Contingency Plan == | == Contingency Plan == | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
| Line 181: | Line 183: | ||
<!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --> | <!-- The Fedora Release Notes inform end-users about what is new in the release. Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ --> | ||
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --> | <!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the documentation team and shipped with the release. --> | ||
* | * systemd now verifies that calling process when it attempt to manage a service, using SELinux Policy | ||
== Comments and Discussion == | == Comments and Discussion == | ||
Latest revision as of 12:47, 27 September 2012
SELinux Systemd Access Control
Summary
We need systemd to do SELinux access checking whether or not a process is allowed to manage a unit file.
Owner
- Name: Daniel Walsh
- Email: <dwalsh@redhat.com>
Current status
- Targeted release: [Fedora 18]
- Last updated: Sep 21 2012
- Percentage of completion: 100%
selinux-policy fixes are in Fedora 18.
systemd-192-1.fc18.x86_64 selinux-policy-3.11.1-26.fc18.noarch
Detailed Description
In previous versions of Fedora/RHEL we were able to control which applications/users were able to start/stop services based on the label of the SYSV Init Script. With the advent of systemd we lost this ability since systemd starts and stops all services, and users and processes talk to systemd using systemctl.
Benefit to Fedora
We can better lock down services, for example: Currently NetworkManager needs to be able to start and stop the ntpd service. Currently the only way we can allow NetworkManager to start the ntpd service is to allow it to start/stop any service including security services like iptables/firewalld. Similarly with confined administrators, I would like to define a web administrator that can only manager files in /var/www/html, and start and stop the httpd service, without this feature I have to allow the confined admin to start/stop all services.
Scope
SELinux Policy needs to be written to govern which domains are able to control which units, (completed) Systemd has to be modified to look at the label of the calling process and the label of the unit file that the caller wants to manage, and then ask SELinux whether or not the caller is allowed the access.
How To Test
We can write a test suite to setup different success and failure situations. for example cause a process to run as NetworkManager_t, and execute the systemctl start ntpd.service (Should Succeed) Another attempt would be systemd start httpd.service (Should Fail) Try out confined administrators for webadm_t, and make sure he can only start and stop the httpd service.
Normal system testing should quickly show if there are bugs in the code.
Setup a confined user as guest_u and make sure he is not able to shut the machine down.
User Experience
Since unconfined_t is normal label of the user starting and stopping services, this fix should not effect normal administration of the system.
Dependencies
Systemd has accepted the patch in a release that is in F18.
Contingency Plan
We can continue allowing all access, but this is less secure then what we had in Fedora 15.
Documentation
This feature is to use SELinux to enforce Access Control to critical features like starting/stoping system services. Theoretically it should only effect the systemd developers and selinux policy writers.
Policy changes involve a new class called "service", with the following permissions
class service
{
start
stop
status
reload
kill
load
enable
disable
}
Since SELinux access checks and systemd access do not line up exactly, we have created a table to connect systemd (systemctl) commands with the appropriate SELinux access.
/* Define a mapping between the systemd method calls and the SELinux access to check. We define two tables, one for access checks on unit files, and one for access checks for the system in general. If we do not find a match in either table, then the "undefined" system check will be called. */
static const char *unit_methods[][2] = {{ "DisableUnitFiles", "disable" },
{ "EnableUnitFiles", "enable" },
{ "GetUnit", "status" },
{ "GetUnitByPID", "status" },
{ "GetUnitFileState", "status" },
{ "Kill", "stop" },
{ "KillUnit", "stop" },
{ "LinkUnitFiles", "enable" },
{ "ListUnits", "status" },
{ "LoadUnit", "status" },
{ "MaskUnitFiles", "disable" },
{ "PresetUnitFiles", "enable" },
{ "ReenableUnitFiles", "enable" },
{ "Reexecute", "start" },
{ "Reload", "reload" },
{ "ReloadOrRestart", "start" },
{ "ReloadOrRestartUnit", "start" },
{ "ReloadOrTryRestart", "start" },
{ "ReloadOrTryRestartUnit", "start" },
{ "ReloadUnit", "reload" },
{ "ResetFailed", "stop" },
{ "ResetFailedUnit", "stop" },
{ "Restart", "start" },
{ "RestartUnit", "start" },
{ "Start", "start" },
{ "StartUnit", "start" },
{ "StartUnitReplace", "start" },
{ "Stop", "stop" },
{ "StopUnit", "stop" },
{ "TryRestart", "start" },
{ "TryRestartUnit", "start" },
{ "UnmaskUnitFiles", "enable" },
{ NULL, NULL }
};
static const char *system_methods[][2] = { { "ClearJobs", "reboot" },
{ "FlushDevices", "halt" },
{ "Get", "status" },
{ "GetAll", "status" },
{ "GetJob", "status" },
{ "GetSeat", "status" },
{ "GetSession", "status" },
{ "GetSessionByPID", "status" },
{ "GetUser", "status" },
{ "Halt", "halt" },
{ "Introspect", "status" },
{ "KExec", "reboot" },
{ "KillSession", "halt" },
{ "KillUser", "halt" },
{ "ListJobs", "status" },
{ "ListSeats", "status" },
{ "ListSessions", "status" },
{ "ListUsers", "status" },
{ "LockSession", "halt" },
{ "PowerOff", "halt" },
{ "Reboot", "reboot" },
{ "SetUserLinger", "halt" },
{ "TerminateSeat", "halt" },
{ "TerminateSession", "halt" },
{ "TerminateUser", "halt" },
{ NULL, NULL }
};
Policy for this would look like.
sesearch -A -s NetworkManager_t -c service
Found 5 semantic av rules:
allow NetworkManager_t dnsmasq_unit_file_t : service { start stop status reload kill load } ;
allow NetworkManager_t nscd_unit_file_t : service { start stop status reload kill load } ;
allow NetworkManager_t ntpd_unit_file_t : service { start stop status reload kill load } ;
allow NetworkManager_t pppd_unit_file_t : service { start stop status reload kill load } ;
allow NetworkManager_t polipo_unit_file_t : service { start stop status reload kill load } ;
sesearch -A -s webadm_t -c service
Found 1 semantic av rules:
allow webadm_t httpd_unit_file_t : service { start stop status reload kill load enable disable } ;
Release Notes
- systemd now verifies that calling process when it attempt to manage a service, using SELinux Policy