Is there a reason that 'screen' was chosen over or 'vlock' for xccdf_org.ssgproject.content_rule_package_screen_installed?
'vlock' is the more target specific and allows for locking *all* user consoles by running 'vlock -a'.
Thanks,
Trevor
On Monday, November 13, 2017 1:02:00 PM EST Trevor Vaughan wrote:
Is there a reason that 'screen' was chosen over or 'vlock' for xccdf_org.ssgproject.content_rule_package_screen_installed?
Common Criteria requirements state that we need to have a self locking screen after a certain number of minutes of inactivity. Screen can do it, vlock can't.
-Steve
'vlock' is the more target specific and allows for locking *all* user consoles by running 'vlock -a'.
Thanks,
Trevor
Steve,
So, would tmux be a valid alternative? It can do the same as screen in that respect.
Also, either case is going to leave the base VT wide open and able to be connected to fairly easily.
Would using an Exit Trap with TMOUT to spawn vlock work? That should work in all cases (well, for bash and zsh anyway). This would also seem to be more in line with the requirement since a 'vlock -a' will lock *all* user terminals, not just one.
On Mon, Nov 13, 2017 at 3:03 PM, Steve Grubb sgrubb@redhat.com wrote:
On Monday, November 13, 2017 1:02:00 PM EST Trevor Vaughan wrote:
Is there a reason that 'screen' was chosen over or 'vlock' for xccdf_org.ssgproject.content_rule_package_screen_installed?
Common Criteria requirements state that we need to have a self locking screen after a certain number of minutes of inactivity. Screen can do it, vlock can't.
-Steve
'vlock' is the more target specific and allows for locking *all* user consoles by running 'vlock -a'.
Thanks,
Trevor
On Tue, Nov 14, 2017 at 10:27:04AM -0500, Trevor Vaughan wrote:
Steve,
So, would tmux be a valid alternative? It can do the same as screen in that respect.
Hello,
I agree with that. For me screen is almost dead and buggy. Tmux would be an appreciable and modern alternative.
Regards, Olivier Bonhomme
On Tuesday, November 14, 2017 10:27:04 AM EST Trevor Vaughan wrote:
Steve,
So, would tmux be a valid alternative? It can do the same as screen in that respect.
I remember that we had to make screen MLS aware. No such work has been done to tmux. It was not part of the TOE and therefore not subjected to the review and bug fixing that screen got. Not saying it couldn't be...it just hasn't been through CC to verify how it works.
Also, either case is going to leave the base VT wide open and able to be connected to fairly easily.
That is a requirement. If you have a multi user system, they need to independently work and time out independently.
Would using an Exit Trap with TMOUT to spawn vlock work?
What if you're sitting in vi editing a daemon config and get a long phone call? It has to be independent of bash.
That should work in all cases (well, for bash and zsh anyway). This would also seem to be more in line with the requirement since a 'vlock -a' will lock *all* user terminals, not just one.
:-) Which I'm sure will make the other users real happy. The correct use and configuration for screen can be found in the cc-config-rhel71 package with lots of other guidance on how to meet requirements.
-Steve
On Mon, Nov 13, 2017 at 3:03 PM, Steve Grubb sgrubb@redhat.com wrote:
On Monday, November 13, 2017 1:02:00 PM EST Trevor Vaughan wrote:
Is there a reason that 'screen' was chosen over or 'vlock' for xccdf_org.ssgproject.content_rule_package_screen_installed?
Common Criteria requirements state that we need to have a self locking screen after a certain number of minutes of inactivity. Screen can do it, vlock can't.
-Steve
'vlock' is the more target specific and allows for locking *all* user consoles by running 'vlock -a'.
Thanks,
Trevor
Ah, I didn't realize that there were MLS hooks in there. That makes more sense considering that the 800-53 requires a CC evaluation for all Federally utilized products.
Could the prose in the SSG be updated to refer to what exactly needs to be done on the user side? Do we need to intstall the cc-config-rhel71 package on all systems to meet this requirement or is there some subset that we can apply? In that vein, should the STIG require that the cc-config-rhel71 package be applied?
As it stands, 'install screen' really doesn't tell me a lot about what I need to force the users to actually *do* with screen which, thanks to this thread, I now have (and am quite pleased with).
As a side note, finding the cc-config-rhel71 package is really non-trivial.
Thanks,
Trevor
On Tue, Nov 14, 2017 at 3:15 PM, Steve Grubb sgrubb@redhat.com wrote:
On Tuesday, November 14, 2017 10:27:04 AM EST Trevor Vaughan wrote:
Steve,
So, would tmux be a valid alternative? It can do the same as screen in
that
respect.
I remember that we had to make screen MLS aware. No such work has been done to tmux. It was not part of the TOE and therefore not subjected to the review and bug fixing that screen got. Not saying it couldn't be...it just hasn't been through CC to verify how it works.
Also, either case is going to leave the base VT wide open and able to be connected to fairly easily.
That is a requirement. If you have a multi user system, they need to independently work and time out independently.
Would using an Exit Trap with TMOUT to spawn vlock work?
What if you're sitting in vi editing a daemon config and get a long phone call? It has to be independent of bash.
That should work in all cases (well, for bash and zsh anyway). This would also seem to be more in line with the requirement since a 'vlock -a' will lock *all* user terminals, not just one.
:-) Which I'm sure will make the other users real happy. The correct use and configuration for screen can be found in the cc-config-rhel71 package with lots of other guidance on how to meet requirements.
-Steve
On Mon, Nov 13, 2017 at 3:03 PM, Steve Grubb sgrubb@redhat.com wrote:
On Monday, November 13, 2017 1:02:00 PM EST Trevor Vaughan wrote:
Is there a reason that 'screen' was chosen over or 'vlock' for xccdf_org.ssgproject.content_rule_package_screen_installed?
Common Criteria requirements state that we need to have a self locking screen after a certain number of minutes of inactivity. Screen can do it,
vlock
can't.
-Steve
'vlock' is the more target specific and allows for locking *all* user consoles by running 'vlock -a'.
Thanks,
Trevor
On Tuesday, November 14, 2017 3:58:19 PM EST Trevor Vaughan wrote:
Ah, I didn't realize that there were MLS hooks in there. That makes more sense considering that the 800-53 requires a CC evaluation for all Federally utilized products.
Could the prose in the SSG be updated to refer to what exactly needs to be done on the user side?
I think so.
Do we need to intstall the cc-config-rhel71 package on all systems to meet this requirement or is there some subset that we can apply?
The cc-config-rhel71 package provides the guidance on how the OS was able to pass its CC evaluation. This information should be taken into account when writing security guidance. Not everyone needs to install it. Only a few people writing the prose that everyone else will follow needs to do it.
In that vein, should the STIG require that the cc-config-rhel71 package be applied?
No. But it should take into account what was taken through CC and how the system was configured when it passed certification. My view of the world is like this:
NIAP creates PP Vendor meets requirements and produces ECG (Evaluated Configuration Guide) ECG feeds into Security baselines as it explains security features People configure to a baseline (PCI-DSS/USGCB/STIG/NISPOM/...) Monitor for new attacks Update PP for new mitigations....and we loop back to the top and do it again.
As it stands, 'install screen' really doesn't tell me a lot about what I need to force the users to actually *do* with screen which, thanks to this thread, I now have (and am quite pleased with).
As a side note, finding the cc-config-rhel71 package is really non-trivial.
Sorry about that...where it goes is out of my hands.
-Steve
On Tue, Nov 14, 2017 at 3:15 PM, Steve Grubb sgrubb@redhat.com wrote:
On Tuesday, November 14, 2017 10:27:04 AM EST Trevor Vaughan wrote:
Steve,
So, would tmux be a valid alternative? It can do the same as screen in
that
respect.
I remember that we had to make screen MLS aware. No such work has been done to tmux. It was not part of the TOE and therefore not subjected to the review and bug fixing that screen got. Not saying it couldn't be...it just hasn't been through CC to verify how it works.
Also, either case is going to leave the base VT wide open and able to be connected to fairly easily.
That is a requirement. If you have a multi user system, they need to independently work and time out independently.
Would using an Exit Trap with TMOUT to spawn vlock work?
What if you're sitting in vi editing a daemon config and get a long phone call? It has to be independent of bash.
That should work in all cases (well, for bash and zsh anyway). This would also seem to be more in line with the requirement since a 'vlock -a' will lock *all* user terminals, not just one.
: :-) Which I'm sure will make the other users real happy. The correct use
and configuration for screen can be found in the cc-config-rhel71 package with lots of other guidance on how to meet requirements.
-Steve
On Mon, Nov 13, 2017 at 3:03 PM, Steve Grubb sgrubb@redhat.com wrote:
On Monday, November 13, 2017 1:02:00 PM EST Trevor Vaughan wrote:
Is there a reason that 'screen' was chosen over or 'vlock' for xccdf_org.ssgproject.content_rule_package_screen_installed?
Common Criteria requirements state that we need to have a self locking screen after a certain number of minutes of inactivity. Screen can do it,
vlock
can't.
-Steve
'vlock' is the more target specific and allows for locking *all* user consoles by running 'vlock -a'.
Thanks,
Trevor
On 11/14/17 5:01 PM, Steve Grubb wrote:
On Tuesday, November 14, 2017 3:58:19 PM EST Trevor Vaughan wrote:
Ah, I didn't realize that there were MLS hooks in there. That makes more sense considering that the 800-53 requires a CC evaluation for all Federally utilized products.
Could the prose in the SSG be updated to refer to what exactly needs to be done on the user side?
I think so.
For sure! Mind opening a ticket?
(catching up on SSG -- apologies if you already did!)
I made the issue super generic but linked it back to this thread so hopefully that can spawn off a flurry of sub-tickets where appropriate.
https://github.com/OpenSCAP/scap-security-guide/issues/2461
Thanks,
Trevor
On Wed, Nov 15, 2017 at 9:12 PM, Shawn Wells shawn@redhat.com wrote:
On 11/14/17 5:01 PM, Steve Grubb wrote:
On Tuesday, November 14, 2017 3:58:19 PM EST Trevor Vaughan wrote:
Ah, I didn't realize that there were MLS hooks in there. That makes more sense considering that the 800-53 requires a CC evaluation for all Federally utilized products.
Could the prose in the SSG be updated to refer to what exactly needs to be done on the user side?
I think so.
For sure! Mind opening a ticket?
(catching up on SSG -- apologies if you already did!)
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
scap-security-guide@lists.fedorahosted.org
-
Olivier BONHOMME -
Shawn Wells -
Steve Grubb -
Trevor Vaughan