But this proposal wouldn't work correctly for case: PermitRootLogin yes PermitRootLogin no
in the config file. Ignore the proposal (I will came with another version yet). Thanks, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team ----- Original Message ----- > From: "Jan Lieskovsky" <[email protected]> > To: [email protected] > Sent: Friday, November 22, 2013 1:08:54 PM > Subject: Re: [PATCH] [RHEL6] Fix OVAL check for '3.4.3.g. Disable SSH Root > Login' rule > > Hello Leland, > > thank you for your review. > > > Shouldn't the check_existence attribute be "at_least_one_exists" rather > > than > > "only_one_exists"? > > I am not sure this would be necessary / the correct scenario. See below. > > > Surprisingly, sshd does not complain about multiple > > PermitRootLogin lines in /etc/ssh/sshd_config. > > Yes (interesting btw.). Looks sshd is recognizing value of the first option > occurrence as the setting to be applied, ignoring the rest (so having > > PermitRootLogin no [PRL] > PermitRootLogin yes > > would still deny the remote SSH logins for root). > > The current proposal returns correct results for all scenarios like > (having 'PRL no' two times in the config, 'PRL no, PRL yes, PRL no', > etc. in the config AFAICT). > > check_existence=only_one_exists succeeds / works properly also for the > case there are multiple instances of "PRL no" present in the config file, > because we are interested only in the first occurrence of that pattern > (<ind:instance datatype="int">1</ind:instance>), which ensures that even > when there are more instances, only one (the first) would be compared > (which is what openssh-server seems to be doing as mentioned above). > > Thank you && Regards, Jan. > -- > Jan iankko Lieskovsky / Red Hat Security Technologies Team > > > > > > > Thanks, > > Leland > > -- > > Leland Steinke, Security+ > > DISA FSO Technical Support Contractor > > tapestry technologies, Inc > > 717-267-5797 (DSN 570) > > [email protected] (gov't) > > [email protected] (com'l) > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:scap- > > > [email protected]] On Behalf Of Jan > > > Lieskovsky > > > Sent: Thursday, November 21, 2013 11:27 AM > > > To: [email protected] > > > Subject: [PATCH] [RHEL6] Fix OVAL check for '3.4.3.g. Disable SSH Root > > > Login' rule > > > > > > > > > Fix / invert the logic of OVAL rule for '3.4.3.g. Disable SSH Root > > > Login' > > > XCCDF rule. > > > > > > On default RHEL-6 system there's no uncommented 'PermitRootLogin yes' > > > present in /etc/ssh/sshd_config configuration file (from the header of > > > the > > > config: > > > > > > # The strategy used for options in the default sshd_config shipped with > > > # OpenSSH is to specify options with their default value where > > > # possible, but leave them commented. Uncommented options change a > > > # default value. > > > > > > From sshd_config(5): > > > > > > PermitRootLogin > > > Specifies whether root can log in using ssh(1). > > > The argument must be “yes”, “without-password”, “forced- > > > commands-only”, or “no”. > > > The default is “yes”. > > > > > > Therefore the default RHEL-6's sshd config is missing explicit > > > PermitRootLogin > > > yes, but defaulting to it. Former implementation (incorrectly) returned > > > 'pass' > > > as result of the scan, even when root login via SSH was allowed (can be > > > tested on former implementation via SSH root attempt). > > > > > > The proposal modifies the implementation the scan check to succeed only > > > in > > > case there's explicit 'PermitRootLogin no' in /etc/ssh/sshd_config, and > > > allows possible comments behinds that definition (since it's valid > > > config > > > form too). > > > > > > Please review. > > > > > > Thank you && Regards, Jan. > > > -- > > > Jan iankko Lieskovsky / Red Hat Security Technologies Team > > > > _______________________________________________ > > scap-security-guide mailing list > > [email protected] > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
