Undo, Automated != Ignore Users
|
|
|
Hello folks,
What I don't remember seeing at developer days was much about how to undo the damage our wonderful language ORML will allow us to wreak on unsuspecting hosts. I am hoping for transactions and I am hoping to know what to do when something goes wrong. The language should build this in from the start otherwise, knowing what was done to a system and how to undo it will be different from tool to tool. A lot of attention has been given to the Windows registry. I will try to focus attention on files. We are still having trouble figuring out how to assess the state of files (textfilecontent??), I can't wait for the problems with tweaking them. As far as patches being trivial as one vendor posited, I think that they are not as trivial as one might think. They have dependencies and more importantly, they have different dependencies than the packages they replace which can cause existing things to break. I believe it is short sighted to blindly patch systems (of course windows update might not have the capabilities of other OSes) but the language should try to do no harm. I have a general question about user interaction. Given that this is part of SCAP, how much user interaction will there be? Will it be defined in the language? For example, if the Modification is to do a call to yum Uvh foo And it asks Installing foo 1.2-3 Installing bar 4.5-6 OK [Yes]/No Do we make these things non interactive? Does ORML have a prepare/propose actions to present to the user or it up to the vendor to do/not do this? Being the list nag I must ask, how will this content get versioned? I figure we are starting on the ground floor so let's do it right from the start (and maybe we can get the rest of SCAP to follow suit). I read slowly so I will be quiet for a while when I get the next proposal. ;) Cheerio, Vladimir Giszpenc DSCI Contractor Supporting US Army CERDEC S&TCD IAD Tactical Network Protection Branch (732) 532-8959 |
||||||||
smime.p7s (4K)
|
|
||||||||
|
|
> The ability to do an undo may be limited on Windows. Some patches are > not uninstallable.... I am sure there are things on Linux and elsewhere that cannot be undone. However, since changing a registry value is undoable and so are file edits, undo is very valuable nonetheless. If we don't make it part of the language, we will be handicapped. Even your statement suggests many patches on Windows *are* uninstallable. Regards, Vladimir Giszpenc DSCI Contractor Supporting US Army CERDEC S&TCD IAD Tactical Network Protection Branch (732) 532-8959 |
||||||||
|
|
||||||||
|
|
||||||||
|
|
||||||||
|
|
||||||||
|
|
|
||||||||
|
|
I would say that any state that can be tested for in OVAL is a good place to
start. It seems to me that we could also have common/core things that are applicable to ORML. As far as doing this incrementally, I could not agree more. Though spending a little time on a design can't hurt either. in independent namespace Environment_state (un)setting an environment variable textfilecontent54_state modify a file's contents xmlfilecontent_state modify an xml file CRUD attributes CRUD nodes in unix namespace file_state setting file permissions, name, location runlevel_state (un)schedule service to run at a runlevel I think it makes sense to start to create ORML for SCAP (XCCDF) content that is already out there and then build from that. However, adding some undo mechanics to a common/core for the above and other namespaces does not seem out of scope to me. Vladimir Giszpenc DSCI Contractor Supporting US Army CERDEC S&TCD IAD Tactical Network Protection Branch (732) 532-8959 > I am concerned that with the group on this thread that we could talk about > requirements forever; we could even document all of them in a massive > requirements document; we could also all probably come to an agreement on > this massive document covering what is needed. However, this does not > give me a resolution to any of my specific problems that I am looking for > a standard way to resolve. > > I would like to see if we can just tackle smaller pieces of the problem at > a time. I would like to see if others are more interested in incremental > progress than in inventing the perfect modification language. > > Grafting to OVAL seemed to me a natural, incremental step to adding > remediation support for vulnerabilities. I never increased my own scope > to generic modification and state change of system settings. To me state > change is the responsibility of a change management system and not of a > vulnerability assessment and remediation system. > > For those of us that have been in remediation for a long time, we know the > nasty business of doing system changes; however, none of us are pushing > pure change management products. HP has change management products, but > my team is specifically only interested in vulnerability assessment and > remediation. > > I have no incentive to assist in inventing a generic modification > language; I do have incentive to assist in resolving the mapping of > vulnerability assessment content to vulnerability remediation content. > > If the scope grows to generic system change, then we move to use our > existing change management systems until such time as this new language > emerges. > > If the scope can be kept small and kept in the scope of vulnerability > management, then we are happy to continue our same resourcing on > contributions. > > If we can't agree on the scope of why we are working on remediation, then > we might as well focus on assessment. > > -ALX > |
||||||||
|
|
|
||||||||
|
|
| ||||||||