Contest - new Security Patch Check report

[Keith Buck]

Here is your chance to show off your skills and/or help decide on the next reporting format for Security Patch Check.

The current Security Patch Check "human-readable" report hasn't changed much in over four years (mostly for compatibility reasons). Recently, we've gotten several questions like:

- How do I find the bulletin that this recommended action refers to?
- What do these new values in the "Spec" field refer to?
- Why is the report telling me about something that I don't think affects me?

So, we've been looking at ways to improve the reporting scheme to make it more clear and helpful. For all those folks out there who probably have a better idea what you need than I do, and who can probably write a report that meets your needs better than I can, I thought I would pose this as a contest.

Here's the rules:

Post your new report suggestion here. You're welcome to use whatever language you're comfortable in. You can use the machine-parseable output (security_patch_check -m) and do some scripting around it, or if you're not a programmer, you can just make up some theoretical output in an editor.

Anyone interested can vote for their favorites. I'll assign points based on the number of votes for each submission (after activity on this thread drops off)


Some things to think about:

- What pieces of data are most useful to you in the report?
- What format do you want the report in (plain text vs. html, tabular vs. a listing of issues?)

Here's a simple example that Bill Hassell and I worked out, to get you started. It's still plaintext (and not formatted very nicely), but gives direct links to the bulletins:

security_patch_check -qq -m | grep -e ^[A-Z] -e 1Liner -e Warn -e SecBul -e DocID -e PName | sed -e 's"HPSBUX"\
http://www.itrc.hp.com/service/cki/docDisplay.do?docId=HPSBUX"g' -e 's/DocID:/References:/' | more

Have fun :)

-Keith

[Steven E. Protter · Accepted solution]

Very important:

That the patches recommended as missing be verified as available from itrc.

I would find a html report that could be emailed to a public folder or the sysadmin to be a useful not un-necessary toy.

I endorse Bill Hassell and your idea.

With the right data I could develop a shell script that downloads the pathes their dependencies and builds an install depot.

I'd never take the last step, auto install.

:-)

SEP

[Keith Buck]

Ok, well, I guess Stephen gets 10 points for being the first (only one so far) to respond.

Does silence indicate that most people are happy with the current tabular report, or that I need to find a better reward?

Stephen,

We are aware of the desire for dependency analysis. Note that for patches, the itrc patch assessment currently offers a security patch analysis of your system which will include recommended dependencies in a single downloadable file. Any comments on that would also be appreciated.

Anyone else out there have comments?

-Keith

[Florian Heigl (new acc)]

Hey Keith - I'm still waiting for a quiet weekend to even try out the first response.
I think more people reply over time.

Until now I used to security patch check, but always forgot where to look up the corresponding information. luckily that system is locked down already, so most issues didn't apply, but fetching the reports has always been an item on my list.

[Keith Buck]

Thanks for the response. I will be patient :)

Anybody that needs help (e.g. "What does this field mean?!?!?" or "why isn't this information in the machine-parseable output?") please post and I'll see if I can help.

-Keith

[Bill Hassell]

One of the goals I talked with Keith about was to be able to run the SPC (security patch check) program and get a clean report if all was well. But if there was a problem, there would be an easy way to find the associated security document. The problem with the current format was the simple list of security bulletins like:

304
1047
1099
280r1
295r2

and so on. The bulletins are not patches but specific steps that need to be taken. Finding these quickly led to the snippet of code above. Now these can be put into an ignore file ($HOME/.spc_ignore) like this:

111r2 # very old Ignite issue
188r1 # Java 1.4.2.04 Java Web Start (1.0.1.01 or higher for HP-UX 11.x)
205r1 # TCP sequence numbers (implemented in nddconf)
231 # Visualize Conference (Xwindows) not applicable
239r1 # swacl for swinstall (allow/deny remote access to patch info)
150 # swacl -l host (removes remote probing of installed patches)

etc, but there was no method to acknowledge patch warnings where removing the patch was not necessary for a specific system. The -qq option does suppress the warnings but that means you'll not see any new ones.

So the goal is to have a list of 1-liners for action, or no output when all recommendations have been handled or acknowledged. This is especially useful for multiple system reports.

A minor improvement: I download the latest security catalog which is named "security_catalog2" but the program is expecting "./security_catalog" so I have to either rename the file or use the -c option.

[H.Merijn Brand (procura]

Everything is parsable .... with Perl.
Posts like this make me realize that some of my cli one-liners are more complicated that the avarage sysadm would even think of trying to put in a script.

I agree with SEP that the thing I would prefer most is a summary with what patches to install, with wget'able url links *including* the prerequisites and dependencies.

Most of the times I used it, I parsed the report, filtered the patches to install, checked if I already had them in another update folder, if not fetch them from HP ftp, check for deps, fetch deps etc. All semi-automated. But a final section that I could run as script (just as if I got it from SUM) would be marvelous

No XML please.

Enjoy, Have FUN! H.Merijn

[Florian Heigl (new acc)]

Procura,
Your oneliners surely are...

for about a year I'm just trying to get a really advanced and good ksh course here in germany (perl has only become an option at our customer site in the last year or so) - it is almost impossible.
many people will offer them, but by simply asking them about specific differences between posix, ksh and ksh93 You'll turn away from them, they probably would even have to look up when ksh93 was released.

I know a bit about what reasonable code looks like, but most sysadmins I know will reproducably run away whereever the word 'regex' is just mentioned. this seems to apply generation after generation, and it includes myself. I know how much time and effort I waste due to this fact, but I'm still waiting for a sunny, bright and wonderful day when I sit down to grok this, perl, xml and many other handy tools.

Until You wire up Your synapses for regex and similar things, they just don't become parseable. :)

I even had to show some of the people here how to edit a command line in vi. most every-day sysadmin tasks just don't require it, often there even are processes against it.

i.e. see the HP sw-recovery manuals:
It says in short to re-mirror a vg, the tech should do for i in 1 2 [ ... ] ; lvextend -m1 $i ... or something like that, instead of just gathering the exact data from vgdisplay, and a reasonable sysadmin will follow that well-tested rule. I'm not so reasonable, which probably is why I like messed up situations, where some rules don't apply and I need to use my brain...

(enough babble :)

[Florian Heigl (new acc)]

I tried Your little script last night, and I think it well serves it's purpose, I don't feel I'd need much more.

About the 'solved' issues - I wouldn't start the effort of keeping a file with a whitelist on bulletins read and fixed in a textfile.

rather I'd like to tell the patchcheck to use a baseline date. for example, the ignite golden image or patch bundles I use would fix all features until 20041231, and the next maybe image will be released on 20050501, so it'd be enough to just skip over the reports until 2005, which might leave 10 bulletins reported, which might be solved by administrative means in two weeks, after that, the baseline date could be adapted.

this should keep line noise low and also take little effort.

[Bill Hassell]

Just a note about the whitelist--it has existed since the beginning (if I remember correctly) of the SPC code. The .spc_ignore file is definitely useful as patch/fix dates are a bit unreliable. I remember a security bulletin that had 3 different dates because it was related to a previous bulletin and it took quite a while to figure out if the fix was in another patch or manual step, etc. The bulletin number seems to be the best for manual fixes.

[Keith Buck]

Bill,

The .spc_ignore file was added in the B.02.00 release. We did not feel it was necessary when the analysis only covered patches (it was easier to apply the patch than to "ignore" the issue) but it is the only way to acknowledge manual actions have been applied.

Florian,

Thanks for the input. I do think dates for bulletins would be more confusing than they look at first (date of this revision, date this action was added to the bulletin, date of bulletin revision zero, etc.?)

I will look into this as a way to acknowledge warnings (which are indeed keyed off of date).

-Keith

[Keith Buck]

Updated script to deal with GN and MA bulletins:

security_patch_check -qq -m | grep -e ^[A-Z] -e 1Liner -e Warn -e SecBul -e DocID -e PName | sed -e 's"HPSB"\
http://www.itrc.hp.com/service/cki/docDisplay.do?docId=HPSB"g' -e 's/DocID:/References:/' | more

[Keith Buck]

By the way, the new Software Assistant incorporates the feedback from this thread, and has a comprehensive html report with direct bulletin links.

https://www.hp.com/go/swa