Learn more about these different git repos.
Other Git URLs
The interface need to have a mode in which it enforces some security checks on the file it is going to read.
Here is the part of the IRC discussion that lead to creation of this ticket:
<sgallagh> For the log config files, it would probably be smart to ensure that it will only load those that are unreadable/writeable by anyone but root.
<dpal> sgallagh, good point but then it should be a part of the INI interface.
<dpal> sgallagh, something like "enforce security flag"
<dpal> sgallagh, that will force the checks when ini file is open
<sgallagh> dpal: Not a bad idea.
<dpal> sgallagh, I will add a ticket to capture this idea
<sgallagh> dpal: Rather than just a security flag, it should probably be a mask.
<sgallagh> dpal: That way users of the interface can specify which portions of the file must be unreadable and by whom.
<dpal> sgallagh, portions of the file? You mean sections on the INI?
<sgallagh> sorry, bad choice of words
<sgallagh> in terms of rwxrwxr-- (for example).
<dpal> sgallagh, in general - ownership and permission rules for the file
<sgallagh> It should be possible with a mask to say "Only open this if only owner and group has write access" or, more restrictively "Only if owner has read access"
<dpal> and owner is root
<dpal> or root and admin
<sgallagh> Yeah, that would be another parameter. Valid user id.
<sgallagh> Or group id
<dpal> it would be one parameter - security descriptor :)
<dpal> One would create security descriptor with rules and pass it in.
<dpal> If the argument is NULL - no checks, if security descriptor is passed, the file will be validated based on the rules defined in the descriptor.
<dpal> sgallagh, something like this...
Simo brought a point that SELinux would do. So this is an ER for consider in future when we port to other platforms.
Fields changed
description: The interface need to have a mode in which it enforces some security checks on the file it is going to read.
Here is the part of the IRC discation that lead to creation of this ticket:
<sgallagh> For the log config files, it would probably be smart to ensure that it will only load those that are unreadable/writeable by anyone but root. <dpal> sgallagh, good point but then it should be a part of the INI interface. <dpal> sgallagh, something like "enforce security flag" <dpal> sgallagh, that will force the checks when ini file is open <sgallagh> dpal: Not a bad idea. <dpal> sgallagh, I will add a ticket to capture this idea <sgallagh> dpal: Rather than just a security flag, it should probably be a mask. <sgallagh> dpal: That way users of the interface can specify which portions of the file must be unreadable and by whom. <dpal> sgallagh, portions of the file? You mean sections on the INI? <sgallagh> sorry, bad choice of words <sgallagh> in terms of rwxrwxr-- (for example). <dpal> sgallagh, in general - ownership and permission rules for the file <sgallagh> It should be possible with a mask to say "Only open this if only owner and group has write access" or, more restrictively "Only if owner has read access" <dpal> and owner is root <dpal> or root and admin <sgallagh> Yeah, that would be another parameter. Valid user id. <sgallagh> Or group id <dpal> it would be one parameter - security descriptor :) <dpal> One would create security descriptor with rules and pass it in. <dpal> If the argument is NULL - no checks, if security descriptor is passed, the file will be validated based on the rules defined in the descriptor. <dpal> sgallagh, something like this...
Simo brought a point that SELinux would do. So this is an ER for consider in future when we port to other platforms. => The interface need to have a mode in which it enforces some security checks on the file it is going to read.
component: SSSD => INI Parser owner: somebody => dpal
This is required for ELAPI troubleshooting tool.
doc: => 0 docupdated: => 0 proposed: => 1.3 tests: => 0 testsupdated: => 0
The checks are there now. See the metadata related part of the interface.
Commit: bf72472
Should be reworked on top of the new interface.
milestone: SSSD Deferred => Tools 1.0
rhbz: => 0
The new interface also has this function.
blockedby: => blocking: => coverity: => feature_milestone: => milestone: Tools Backlog => Tools 1.0 patch: => 0
design: => design_review: => 0 fedora_test_page: => resolution: => fixed status: new => closed
Metadata Update from @dpal: - Issue assigned to dpal - Issue set to the milestone: Tools 1.0
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/1124
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.