False positives in control os-06

[st739]

command('find / -perm -4000 -o -perm -2000 -type f ! -path '/proc/*' -print 2>/dev/null | grep -v '^find:'')
If I create an empty file and chmod 7777 empty_file (I know it's a stupid thing to do, but users do it on my systems), it comes up positive. But it's not an executable file format. Also, when this find is run as root, it traverses directories inaccessible to non-root users and reports files that may not be visible to or accessible by non-root users. (If a file is suid or sgid root and is only accessible by or executable by root is it a problem?) I know this is nitpicking, but the (non-chef) compliance check run against my systems by corporate central monitoring keeps requiring me to fix these non-problems. It would be great if moving to chef removed these issues rather than perpetuating them.
Simon

[atomic111]

Hi @st739,

you need a test, which test first the ownership of a file and who can access it.

It is not really a problem that a file has a suid bit and is only accessible or executable by root.

Our chef cookbook (https://github.com/dev-sec/chef-os-hardening) can remove all suid bits from you system (example json):

{
   "security" : {"suid_sgid": { 
        "remove_from_unkown" : true
        }
    },
    "run_list":[
        "recipe[os-hardening]",
        "recipe[chef-solo-search]"
    ]
}

Some words about our tests: The main goal why we created the tests is to check our implementation with chef, ansible and puppet. So that we can follow a test-driven development approach.

Maybe you have to adjust the tests to your specific environment.

[rndmh3ro]

f I create an empty file and chmod 7777 empty_file (I know it's a stupid thing to do, but users do it on my systems), it comes up positive. But it's not an executable file format.

If you chmod 777 the file, it's empty and can't be executed. But since it's writeable by anyone, anyone could write malicious code into the file and execute it. So it should not have exec-permissions.

[atomic111]

@st739 do you have any further progress or information for us?

[st739]

My perspective is a 'brownfields' one - where multiple systems already exist and were built without the benefit of a deployment and configuration management tool. As you say, your tests are designed to test your automated implementation, so in this context, I think we should end this issue.
Thanks, and regards, Simon

[st739]

Hi,
I've closed the issue in Github. As I mentioned there, my point of
view is based on the existence of large numbers of systems built
without the benefit of a deployment and configuration management tool
rather than using the tests to confirm or validate an expected
configuration.
Regards, Simon

On 7/25/16, Patrick Münch notifications@github.com wrote:

@st739 do you have any further progress or information for us?

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#40 (comment)

[chris-rock]

@st739 @atomic111 Since it would be useful to be able to use the tests with the need for any configuration management tools, we could think about the following:

• use a base os hardening level 1 and introduce another level 2 that is more secure
• we could also use attributes in inspec to make some parts configurable

@st739 Very soon, InSpec will support proper profile inheritance as well. (which we would use for my 1 proposal). In that case you could use our profile and easily adapt your customizations. Would that be helpful?