Hi,
to help the OpenSCAP integration, I prepared a wiki page that contains options which have a security impact -- either positive (drop root) or negative (ignore certificate validation issues).
I also tried to explain the effect of the options along with the description. There are some more items that can be included, but I wasn't sure about them myself, like: * should obfuscated passwords be mentioned? I wasn't sure because on one hand it really doesn't provide any benefit, on the other hand, the option can be used to check a compliance box that requires no passwords be stored in files.. * should the page warn against the auth-option-that-shall-not-be-mentioned or politely deny its existence? :-) * What about fd_limit ? Should resource consumption be considered a security property, especially if we already honor system default? I think here the default is enough, so I didn't document that option.
Please provide your comments or edit the wiki directly. Thanks!
On 09/30/2015 09:38 AM, Jakub Hrozek wrote:
Hi,
to help the OpenSCAP integration, I prepared a wiki page that contains options which have a security impact -- either positive (drop root) or negative (ignore certificate validation issues).
I also tried to explain the effect of the options along with the description. There are some more items that can be included, but I wasn't sure about them myself, like: * should obfuscated passwords be mentioned? I wasn't sure because on one hand it really doesn't provide any benefit, on the other hand, the option can be used to check a compliance box that requires no passwords be stored in files.. * should the page warn against the auth-option-that-shall-not-be-mentioned or politely deny its existence? :-) * What about fd_limit ? Should resource consumption be considered a security property, especially if we already honor system default? I think here the default is enough, so I didn't document that option.
Please provide your comments or edit the wiki directly. Thanks! _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
I was thinking about 'cached_auth_timeout' timeout. If misconfigured and set for really long time changes of passwords on server would be ignored. I know that same effect could be achieved by maintaining SSSD in offline mode... What do you think?
On 09/30/2015 09:38 AM, Jakub Hrozek wrote:
Hi,
to help the OpenSCAP integration, I prepared a wiki page that contains options which have a security impact -- either positive (drop root) or negative (ignore certificate validation issues).
I also tried to explain the effect of the options along with the description. There are some more items that can be included, but I wasn't sure about them myself, like: * should obfuscated passwords be mentioned? I wasn't sure because on one hand it really doesn't provide any benefit, on the other hand, the option can be used to check a compliance box that requires no passwords be stored in files.. * should the page warn against the auth-option-that-shall-not-be-mentioned or politely deny its existence? :-) * What about fd_limit ? Should resource consumption be considered a security property, especially if we already honor system default? I think here the default is enough, so I didn't document that option.
Please provide your comments or edit the wiki directly. Thanks! _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Should not we also mention dreadful option ldap_auth_disable_tls_never_use_in_production ?
I know it's undocumented, but I suppose OpenSCAP should report its presence anyway.
On Wed, Sep 30, 2015 at 10:07:48AM +0200, Pavel Reichl wrote:
Should not we also mention dreadful option ldap_auth_disable_tls_never_use_in_production ?
That's what I was trying to ask :)
* should the page warn against the auth-option-that-shall-not-be-mentioned or politely deny its existence? :-)
I think it depends on the presentation a bit, if the tool just tells user 'remove this option' than it would be fine to include it. If the tool would present a list of options, like the wiki page does, then no.
I guess we can sort this out with the SCAP developers..
On (30/09/15 09:38), Jakub Hrozek wrote:
Hi,
to help the OpenSCAP integration, I prepared a wiki page that contains options which have a security impact -- either positive (drop root) or negative (ignore certificate validation issues).
I also tried to explain the effect of the options along with the description. There are some more items that can be included, but I wasn't sure about them myself, like:
- should obfuscated passwords be mentioned? I wasn't sure because on one hand it really doesn't provide any benefit, on the other hand, the option can be used to check a compliance box that requires no passwords be stored in files..
- should the page warn against the auth-option-that-shall-not-be-mentioned or politely deny its existence? :-)
- What about fd_limit ? Should resource consumption be considered a security property, especially if we already honor system default? I think here the default is enough, so I didn't document that option.
Please provide your comments or edit the wiki directly. Thanks!
What about:
simple_deny_users (string) Comma separated list of users who are explicitly denied access.
simple_deny_groups (string) Comma separated list of groups that are explicitly denied access. This applies only to groups within this SSSD domain. Local groups are not evaluated.
Whitelisting is much secure than blacklisting.
LS
On Wed, Sep 30, 2015 at 10:37:30AM +0200, Lukas Slebodnik wrote:
On (30/09/15 09:38), Jakub Hrozek wrote:
Hi,
to help the OpenSCAP integration, I prepared a wiki page that contains options which have a security impact -- either positive (drop root) or negative (ignore certificate validation issues).
I also tried to explain the effect of the options along with the description. There are some more items that can be included, but I wasn't sure about them myself, like:
- should obfuscated passwords be mentioned? I wasn't sure because on one hand it really doesn't provide any benefit, on the other hand, the option can be used to check a compliance box that requires no passwords be stored in files..
- should the page warn against the auth-option-that-shall-not-be-mentioned or politely deny its existence? :-)
- What about fd_limit ? Should resource consumption be considered a security property, especially if we already honor system default? I think here the default is enough, so I didn't document that option.
Please provide your comments or edit the wiki directly. Thanks!
What about:
simple_deny_users (string) Comma separated list of users who are explicitly denied access. simple_deny_groups (string) Comma separated list of groups that are explicitly denied access. This applies only to groups within this SSSD domain. Local groups are not evaluated.
Whitelisting is much secure than blacklisting.
Good idea, added: https://fedorahosted.org/sssd/wiki/SecuritySensitiveOptions?action=diff&...
On (30/09/15 09:38), Jakub Hrozek wrote:
Hi,
to help the OpenSCAP integration, I prepared a wiki page that contains options which have a security impact -- either positive (drop root) or negative (ignore certificate validation issues).
I also tried to explain the effect of the options along with the description. There are some more items that can be included, but I wasn't sure about them myself, like:
- should obfuscated passwords be mentioned? I wasn't sure because on one hand it really doesn't provide any benefit, on the other hand, the option can be used to check a compliance box that requires no passwords be stored in files..
- should the page warn against the auth-option-that-shall-not-be-mentioned or politely deny its existence? :-)
- What about fd_limit ? Should resource consumption be considered a security property, especially if we already honor system default? I think here the default is enough, so I didn't document that option.
Please provide your comments or edit the wiki directly. Thanks!
I'm not sure about security implication but it might be good to avoid using plantext passwords for authtok in sssd.conf.
ldap_default_authtok_type = password.
I'm not sure about obfuscated_password. What do you think?
LS
On Wed, Oct 14, 2015 at 08:49:26AM +0200, Lukas Slebodnik wrote:
On (30/09/15 09:38), Jakub Hrozek wrote:
Hi,
to help the OpenSCAP integration, I prepared a wiki page that contains options which have a security impact -- either positive (drop root) or negative (ignore certificate validation issues).
I also tried to explain the effect of the options along with the description. There are some more items that can be included, but I wasn't sure about them myself, like:
- should obfuscated passwords be mentioned? I wasn't sure because on one hand it really doesn't provide any benefit, on the other hand, the option can be used to check a compliance box that requires no passwords be stored in files..
- should the page warn against the auth-option-that-shall-not-be-mentioned or politely deny its existence? :-)
- What about fd_limit ? Should resource consumption be considered a security property, especially if we already honor system default? I think here the default is enough, so I didn't document that option.
Please provide your comments or edit the wiki directly. Thanks!
I'm not sure about security implication but it might be good to avoid using plantext passwords for authtok in sssd.conf.
ldap_default_authtok_type = password.
I'm not sure about obfuscated_password. What do you think?
It's better to use a different mechanism than password in the first place :-)
The obfuscation is just that -- it hides the password, but the password still can be retrieved. So IMO the obfuscated password is more or less helpful for auditors that need a check a box that says that no passwords are allowed in config files..
So I think in this case the OpenSCAP team must decide what exactly they are after..
sssd-devel@lists.fedorahosted.org