Jeff, This actually hits on a similar request that I have (but for different reasons). I would like a stable interface from which I could tell the update revision of a system.
I have a very large government customer who (as part of their security configuration hardening and assessment) process have a very real need to detect OS version and update levels so that they can determine which actions/checks to apply. In a past life working on JASS, we were told to not test for patch or update levels but rather to test whether a specific feature is present, and while I understand the merits of this methodology, it does not always provide a complete solution (without making significant assumptions about how the system was installed/maintained). For example, is the feature not present or has it been removed or simply not installed? Also, the existence of some features also can not be easily tested using automated tools without imposing a great burden on the tool developer. It sounds like you may be in a similar boat. What do you think? Cross-posting to security-discuss to get their feedback as well. g Jeff Victor wrote: > Hi Kevin, > > I believe that you cannot patch your way from U1 to U5 - i.e. that the > system is missing some functionality that would be there if you had > applied the updates - but your point is still valid. I will look into > the correctness of using patch levels to detect feature availability. > > On Mon, Nov 17, 2008 at 6:09 PM, Young, Kevin <[EMAIL PROTECTED]> wrote: >> Jeff, >> I am wondering about the logic in how the script identifies specific >> versions. It appears that you are looking at /etc/release to define >> this. This seems to limit some features of your script because I have a >> Solaris 10 update 1 system that has been updated to 05/08 (update 5) but >> /etc/release still reflects update 1 (updated using 05/08 patch bundle). >> >> I am using CPU caps but your tool doesn't recognize that I have that >> feature available. Since these features really come from the kernel >> version, would that be a better way to identify release version in your >> script; Just a thought. >> >> In the meantime I tricked the script to think I am on update 5 and I am >> getting better results. >> >> >> -= Kevin =- >> >> >> -----Original Message----- >> From: Jeff Victor [mailto:[EMAIL PROTECTED] >> Sent: Monday, November 10, 2008 9:01 AM >> To: Young, Kevin >> Cc: email@example.com >> Subject: Re: [zones-discuss] Zone Statistics: monitoring resource use of >> zones >> >> On Mon, Nov 10, 2008 at 11:21 AM, Young, Kevin <[EMAIL PROTECTED]> >> wrote: >>> I am curious if you have plans to make it Solaris 10 compatible. >> I do all development on Solaris 10. The script makes an effort to >> distinguish between the different capabilities of the different >> Solaris 10 updates. >> >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Victor >>> Sent: Sunday, November 09, 2008 5:54 PM >>> To: firstname.lastname@example.org >>> Subject: [zones-discuss] Zone Statistics: monitoring resource use of >> zones >>> It has become clear that there is a need to monitor resource >>> consumption of workloads in zones, and an easy method to compare >>> consumption to resource controls. In order to understand how a >>> software tool could fulfill this need, I created an OpenSolaris >>> project and a prototype to get started. If this sounds interesting, >>> you can find the project and Perl script at: >>> http://opensolaris.org/os/project/zonestat/ . >>> >>> If you have any comments, or suggestions for improvement, please let >>> me know on this e-mail list or via private e-mail. > > -- Glenn Brunette Distinguished Engineer Director, GSS Security Office Sun Microsystems, Inc. _______________________________________________ zones-discuss mailing list email@example.com