This is announcing the ASL 2.1 alpha with the stand-alone ASL-Web interface to the [asl-2.0-bleeding] channel. As this is an alpha release, and therefore unsupported code. Please send feedback to support@atomicorp.com rather than post to the forums.

Changelog

- Added ASL Web, stand alone GUI (default account: admin, password: setup)
- First new-architecture module rewrite, kernel_check is now written in C
- Added logic to configure and install the default ASL Web databases
- Added asl-web init script, /etc/init.d/asl-httpd
- Added asl-web sysconfig, /etc/sysconfig/asl-httpd


To install:

yum --enablerepo=asl-2.0-bleeding upgrade asl
yum --enablerepo=asl-2.0-bleeding install asl-web

Scott,

No Fedora 8 packages (i386)
No Fedora 10 packages (i386)

thats weird, they did get built for it. I'll do another run here shortly, see if they get populated correctly.

Update: They should be available now

Thanks Scott that worked!

Can you supply the source of just the new kernel_check in srpms/asl ?

I assume all the tests / checks plan to go to C which is great, but can the source be supplied for anyone wanting to do their own custom checks / mods?

Especially anyone on 'unsupported' distributions

Thanks!

No, Im afraid not. Thats where all the license manager stuff is going. I made a note about you being able to create your own modules though, thats a good feature idea.

Hi Scott,

That is good feature

Can we get control over some of the checks in the compiled binaries? I know it may then stop you getting warnings for certain issues, but these can be documented in the compliance report.

It just bugs me being warned about the kernel and some other checks when I know these. For me then after editing these, when I see red I know something needs my attention fast!

It would be good to be able to turn on / off the warning for any test in the compiled binary, just like php features in asl config.

That is my feature addition / suggestion.

Thanks for listening.

Thanks!

We're following the NIST standards in reference to that, what you'd do in that context is document the risks in your System Security Plan as "Accepted", however you *do* still see them reported. In some cases, depending on the data you're handling, you're not even permitted to accept the risk (PCI DSS, or HIPAA for example). Check out NIST-800-53 if you're interested in the methodology we're following.

Hi Scott,

What about still running kernel and checks as shell scripts, but incorporating the license management into asl itself?

This way you are still able to customize reports if you desire, but you maintain license control ?

As this is alpha it's good to discuss and decide in a path.

It's just taking the users ability to control the kernel check in situations you can't run a asl kernel like a vds or you run xwindows.

I don't need to be told that I have no GRC that's obvious

That is my one and only critism of the new ASL, if a regular kernel_check.sh can be deployed I am happy or the ability to remove the critical alerts telling me what I know

Hey it all comes down to the number of licenses ya wanna buy right?