Add a security policy for Elektra

[sedadas]

The recent log4j vulnerability (CVE-2021-44228) showed how important it is for a vulnerability to be be handled as quickly and as clean as possible.
This prompted me to search if Elektra has an established security policy in place but I couldn't find any.

If Elektra does not have such a policy, there are a few "standard" ways to create it, which would make it easier for researchers to report vulnerabilities:

• normally, a lot of people would add a SECURITY.md file at the root of the project, which would describe how to do this.
• add a page to the website with the same function

There is also a RFC draft which aims to create a standard on how this is done (tl;dr: a special security.txt file is placed under the .well-known/ path on the website to define the security policy).

It is important for vulnerabilities to be easily reportable as this going through a number of steps is seen as a chore and may discover researchers to report issues.

[markus2330]

Thank you very much for reporting! I agree that at least doc/AUTHORS.md should contain some information who may be contacted in which situations.

[flo91]

@markus2330 As this was an issue for FLOSS last semester, we probably can also offer it for the current FLOSS course.

[markus2330]

No, I am afraid I need to do it at some point. It cannot be done by a FLOSS participant.

[joni1993]

Due do recent CVE-2022-3602 and CVE-2022-3786 i want to bring some attention to this topic again.
As elektra is dealing with a potentially critical part of the system there are a few things i miss:

• while there is some documentation on how to do fuzz testing, its very little
• doc/todo/RELEASE.md states there is manual testing involved, but the procedure is not very transparent (i did not find much information on what was done etc) release automation #3536, finalize infos/status #666, Continuous Releases #3519, try out AFL #185)
• Should Elektra have at least some sort of security audit?

[markus2330]

The topic is tagged as 0.9.* which means we definitely plan to do something before 1.0.0.

while there is some documentation on how to do fuzz testing, its very little

It describes how to do fuzz testing. What do you miss? I don't think it belongs to this issue, though.

states there is manual testing involved, but the procedure is not very transparent

Actually, afaik we already automatized all of it, so we can remove this sentence. @mpranj do you still do some manual tests? Can you remove the sentence?

Should Elektra have at least some sort of security audit?

I don't think it is very important:

• As Elektra is a library it cannot do anything more/less than what applications could do anyway (no privilege escalation possible)
• Elektra is designed to only get input from trusted parties (administrators via config files)

But any reviews are very welcome. Which security audit were you thinking of?

[joni1993]

It describes how to do fuzz testing. What do you miss? I don't think it belongs to this issue, though.

Basically I miss the transparency on what is exactly done during manual testing.

Should Elektra have at least some sort of security audit?

I don't think it is very important:

• As Elektra is a library it cannot do anything more/less than what applications could do anyway (no privilege escalation possible)
• Elektra is designed to only get input from trusted parties (administrators via config files)

What about user software using Elektra? I don't know much about the internals but i could imagine it may be possible to somehow corrupt global mount db as non-admin user (e.g. override a mount for /etc/sudoers) or similar (overriding system/admin config from user namespace)
Also kdb can be used as non-admin user, right?

But any reviews are very welcome. Which security audit were you thinking of?
Non specifically - just came to my mind when reading about OpenSSL.

[markus2330]

corrupt global mount db as non-admin user (e.g. override a mount for /etc/sudoers) or similar (overriding system/admin config from user namespace)

No, exactly this is impossible (at least as long the operating system works correctly).

Also kdb can be used as non-admin user, right?

Yes, but it wouldn't allow you to do admin actions, you get a permission error.

See doc/TESTING.md for various workarounds to let the admin tests run on your computer.