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
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
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
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
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.
On Tue, Nov 14, 2017 at 3:15 PM, Steve Grubb
> 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
> > 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
> bug fixing that screen got. Not saying it couldn't be...it just hasn't
> 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
> configuration for screen can be found in the cc-config-rhel71 package with
> lots of other guidance on how to meet requirements.
> > On Mon, Nov 13, 2017 at 3:03 PM, Steve Grubb <sgrubb(a)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
> > > > 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,
> > > can't.
> > >
> > > -Steve
> > >
> > > > 'vlock' is the more target specific and allows for locking
> > > > user
> > > > consoles by running 'vlock -a'.
> > > >
> > > > Thanks,
> > > >
> > > > Trevor