coming soon: consistency checking scripts

Kurt Seifried kseifried at redhat.com
Tue Apr 3 16:17:36 UTC 2012


On 04/03/2012 05:38 AM, Simon Lukasik wrote:
> On 03/19/2012 02:45 PM, Spencer R. Shimko wrote:
>> On 3/16/12 12:47 PM, "Steve Grubb" <sgrubb at redhat.com> wrote:
>>>
>>>
>>>>> Its
>>>>> possible to do this because the basic commands are present. But if you
>>>>> get too
>>>>> far from that using augeas, for example, then the command might not
>>>> exist
>>>>> prior
>>>>> to install. I think busybox has the commands that are using during
>>>>> kickstart.
>>>>
>>>> Is this based on the assumption that the fixes will be applied in a spec
>>>> %post and not a ks %post?
>>>
>>> No. I'd have to see it work. But in the appliance situation they want a
>>> minimal 
>>> system. So, the common denominator is shell and busybox.
>>
>> So all we have to do is get Ruby, Puppet, and Augeas in busy box right? Or
>> perhaps just switch RPM's baked-in Lua interpreter to Ruby.  ;)
>>
> 
> What about small/embedded devices. Or some medical appliances with small
> memory, augeas is simply too heavy for them. So it boils down to shell
> or even C. (Maybe these devices are out of concern for this list. (?))

My personal take on this (and it is in no way reflective of Red
Hat/etc.) is that ideally tools like Aqueduct should support as many
devices, low and high end as possible. Why? I noticed a lot of hospital
equipment with network jacks that was being used to keep my kids alive
and well when they were born. So on a purely selfish basis I'd like to
ensure as much of our infrastructure is as robust as possible. Now the
question is how far down do you go? An extreme example:

http://linux.slashdot.org/story/12/04/02/191203/gnulinux-running-on-an-8-bit-processor

I think in general a good compromise is bash based scripts, an embedded
device with no shell would most likely require a custom solution any
ways which is outside the remit of this project (at least for now). Bash
is universal, relatively lightweight, and easy to work with. For devices
incapable of supporting bash they'll either have to write their own
tests in C/Java/whatever they are using or examine the device some other
way (e.g. talk to the maker, examine source code, whatever).

TLDR: the bash method is probably sufficient to handle low
level/embedded devices sanely, anything else just gets way to
complicated to deal with.

-- 
Kurt Seifried Red Hat Security Response Team (SRT)


More information about the scap-security-guide mailing list