Adding banner messages to the list of selectors.

Rui Pedro Bernardino rui-p-bernardino at ptinovacao.pt
Tue Oct 8 09:13:53 UTC 2013


Hi,

I find setting the login_banner_text in each profile adequate for my needs and I also maintain multiple profiles. Even the bash fixes work perfectly (if you define the text appropriately).

I did change the XCCDF to reflect the profile login_banner_text; inputs/accounts/banners.xml:
(...)
<Rule id="set_system_login_banner" severity="medium">
<title>Modify the System Login Banner</title>
<description>
To configure the system login banner:
<br /><br />
Edit <tt>/etc/issue</tt>. Replace the default text with a message
compliant with the local site policy or a legal disclaimer.
<pre>
<sub idref="login_banner_text"/>	                 <--- HERE. I replaced the DoD text with this.
</pre>
</description>
(...)

This way, both the evals and guides always have the text according to the profile. Ok, seting a large number of different login_banner_text for long banners can be a real pain; if you must, I like the 1st method.


Regards


--
Rui Pedro Bernardino
CTE2/Tecnologias e Desenvolvimento
PT Inovação

From: scap-security-guide-bounces at lists.fedorahosted.org [mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of Cooper, Caleb D.
Sent: segunda-feira, 7 de Outubro de 2013 17:01
To: scap-security-guide at lists.fedorahosted.org
Subject: Adding banner messages to the list of selectors.

This is concerning the RHEL6 content but might also be applicable to others:

At my work, we use a different login banner than the one that the DoD uses and I would like to add content for our banner message. However, I want to do this in such a way that would be useful to other institutions. To that end, I would like to change the way the banner message OVAL checks and XCCDF content are created to allow users to add a large number of banner messages to their profiles without a lot of work. I am planning to design a script which would handle this.

However, there is currently no system in place for me to implement this. I would like this to fit with the overall design strategy of the project so please let me know how you would like me to move forward. So far I have thought of the following methods for a script to programmatically generate this content:

1. Add a folder of text files into the auxiliary folder containing all of the banners with their selector ID as file names. The script would parse these at build time and add them to the "login_banner_text" rule inside the input/systems/accounts/banners.xml file. In addition it would append the full banner message to the "set_system_login_banner" rules. 
Pros:
A. This is the smallest change from the way the banner message is checked now.
B. Would require the very little work or XML knowledge by the user -- as all that would be required is creating a simple text file and adding a single selector to their profile.
Cons:
A. Currently there are no scripts outside the checks/templates folder. As this does not create an oval check it doesn't make sense to keep it there.

2. Create a script which builds entire banner rules based on the contents of files stored in a folder in auxiliary. Therefore, rather than simply appending new messages to the "login_banner_text" and "set_system_login_banner" rules it would create entirely new rules for each banner.
Pros:
A. This would make the output of checks smaller and reduce complexity of each banner rule.
B. Would remove the need to external variables in the banner checks.
Cons:
A. This would vastly increase the size of the banner.xml file.
B. Would require changing the OVAL content logic.
C. Currently there are no scripts outside the checks/templates folder. As this does not create an oval check it doesn't make sense to keep it there.


3. Create a checks template script which generates OVAL content for each supplied banner instead of using the external variables from "login_banner_text".
        Pros:
A. Would simplify the OVAL checks.
B. Would not require a new folder outside the current system of folders.
C. Would fit with the current system of OVAL checks most closely.
        Cons:
A. Does not create any XCCDF content, requiring the user to provide this.
B. Parsing a CSV of banner messages would be problematic, so solution would be to use separate files for each banner -- which does not fit the current system.


If you can help me pick one of these, suggest a better solution, or explain why no change should be made I would appreciate the advice.

Thanks,
Caleb Cooper




More information about the scap-security-guide mailing list