Idea for explicit symlink handling in file_object

[don-patterson]

Hi all,

I'm curious if this conversation has come up before, or if there is a convenient workaround that I've missed. Here's the scenario that motivated me to raise up the discussion:

I work with the Joval engine and recently an issue came up where a compliance scan on Linux intended to confirm that the file /etc/motd exists and has certain (readonly) permissions. On the particular host where this ran, /etc/motd was a symlink to another file that did indeed have the expected permissions. Being a symlink on linux though, it had wide open (777) permissions, and that is what Joval collected. This caused the test to fail, and by the OVAL spec, this appears to be correct behavior. I would argue that the content writer intended for this situation to pass the test.

I talked to Max and he made me aware of the symlink_object that could be used to populate a variable with the value of the symlink target via the canonical_path attribute, and test against that. While possible, this seems pretty tedious, and would have to be done for just about every file object where it would be reasonable to have a symlink instead of a file.

Anyhow, TLDR: What are people's thoughts on adding something to the FileBehaviors for file_objects such as:

- follow_symlinks   (optional -- default='false')('false', 'true')

that would cause the collected file_items to take on the size, permissions+execution bits, and timestamps of the target file, rather than the symlink itself. I suspect this is almost always preferred, but it would be a bit much to suggest defaulting this to 'true`.

Thanks for your time,
Don

[don-patterson]

There is a catch I didn't consider. If you blindly followed symlinks and treated them as files, you could hide an insecure sitation. A symlink's target is one part of several important permissions you would need to check, but you would also need to verify that the chain of parent directories was also sufficiently restricted or else a file could be altered without your knowledge and still pass the tests. Here's a more obvious example, but gets the point across:

[drwxr-xr-x]  root
├── [drwxrwxrwx]  insecure
│   └── [-r--r--r--]  motd.txt
└── [drwxr-xr-x]  secure
    └── [lrwxrwxrwx]  motd.txt -> ../insecure/motd.txt

A test against root/secure/motd.txt would look good by following the symlink and seeing 400 for permissions, but the insecure directory can be modified by anyone, so even though the test would suggest everything's locked down, one could rename insecure/motd.txt and swap in their own file.

Maybe such a symlink feature would open up more problems instead of making the content more convenient.

[solind]

See, @don-patterson, the way around your conundrum is to use the symlink_test...

1. Create a file_object to reach the desired path and recurse up.
2. Create a symlink_object that filters the file_object where type = "symbolic link".
3. Create a file_object based on the canonical_path of the symlink_object and recurse up.
4. Create a definition that combines an intelligently-designed test against the permissions of (1) such that it ignores symlinks, with an existence test for (2), and a repeat of the intelligent permissions test of (1) for (3).
5. Tell @maxullman to create a Slang construct for this abomination.
6. Profit.

[solind]

We could add a behaviors to the symlink_object to determine whether it collects intermediate links or just the final targets... but then we might be talking about a cure worse than the disease.

[don-patterson]

ah yeah, that's interesting. I like that idea.

But like you suggest, I don't know if anyone other than a huge Slang construct could use that effectively.

[solind]

Well... that's why we created Slang, after all. It's not always an easy language to use.

If you were to add such a behavior... how would it behave? Maybe create multiple items for the object -- one for each symlink path it finds in the chain. With the current documentation, all the items would share the same canonical_path value, but have different filepath values. That should make it possible to implement all the checks you need.

[don-patterson]

Yeah, that seems like the least disruptive way to implement this. I have a small concern that it could be startling to have a symlink_object with a specific filepath producing items with different filepaths, but... that's kinda the point I guess.

[solind]

I think it shouldn't be too startling if you have to set a non-default behavior attribute in the object to get it to happen.

[johnulmer-oval]

Thinking out loud, a little.....
Maybe this is what you guys are already suggesting? Not sure. But, what if the symlink item was modified to list any 'chain links' as new elements [0-n]? No new behaviors needed. Just list out each link in the chain if a chain exists. If the original link (filepath) does not start a chain, then no links get listed?

<symlink_item>
<filepath>/some/path/to/a/link</filepath>
<chainlink>/another/path/in/a/first/link/</chainlink>
<chainlink>/another/path/in/a/2nd/link/</chainlink>
<chainlink>/another/path/in/a/3rd/link/</chainlink>
<canonical_path>/path/to/ultimate/link/target</canonical_path>
</symlink_item>

The 'links' could be fed through variables to feed any other test_type.

[solind]

That's a viable alternative. It could be added to something like a 5.12.1 without adding a behavior.

However, if the file path represented a direct link to a canonical_path, then you'd still need a <chainlink status="does not exist" /> to signify non-existence, otherwise the absence of the child entity simply means it wasn't collected.