EXPERIMENTAL_AUDIT Doc Update

[robert-s-lee]

Exalate commented:

Re: EXPERIMENTAL_AUDIT

Issue Description

file system permission for the file should be listed and/or modified. The default has -rw-r--r-- which allows anyone access to the OS to read the audit log.

Suggested Resolution

recommended permission setting for the audit file

Jira Issue: DOC-327

[Amruta-Ranade]

@robert-s-lee @rolandcrosby What should the file permissions be set to? I think it should be
-rw-r----- but I might be wrong.

[Amruta-Ranade]

@robert-s-lee The audit logs are stored in the same directory as the other logs generated by CockroachDB. Should the permissions for the entire directory be changed?

[Amruta-Ranade]

@knz @aaron-crl Can you help me resolve this?

[robert-s-lee]

i believe just the audit file itself. i typically see it own by cockroach user as the only user that can read and write.

[knz]

1. From a technical perspective, the responsibility of which permissions to put on the files (and directories) is that of the operator, not that of the database.

2. The other aspect that's absolutely critical to understand from a security perspective, is that even the regular logs (cockroach.log and the rocksdb log) are not safe to view by non-privileged users because they can contain arbitrary application data and user credentials.

So whatever permission "problem" an admin thinks they have about audit logging, is also a problem for all their log files not just the audit log.

3. From a documentation perspective, we should indeed talk about good permission hygiene when setting up logging (both audit logging and normal logging). The user is responsible to set permissions on either:

• the log directory itself (and, preferably, also the data directory),
• or (preferably) using the umask of the cockroach process directly to impact all the files it creates.

[knz]

So the doc could casually talk about good permission hygiene and provide some examples on how to set this up properly. I don't think this is specific to audit logging.

[aaron-crl]

I don't think this is specific to audit logging.

Absolutely. This ^^. Thanks @knz

We can:
(1) evaluate what we expect the default file creation permissions for CRDB should be (I recommend following @Amruta-Ranade 's suggestion of -rw-r----- for all log files by default).
(2) Add a post-install hardening guide (or steps) to help administrators configure their installation more securely (such as enumerating all files that may contain sensitive data and recommending permissions).

[knz]

It's not just the log files that are created with 0664 - it's pretty much everything, including the data files etc.

Hence my answers:

(1) CockroachDb uses a permission mask of 0664 for all files. It is the administrator's responsibility to constrain this further with umask.

(2) all crdb files (not just files) contain potentially sensitive data. Sites that do not use umask and expect privacy are just mistaken.

IMHO we're making a mountain out of a molehill.

As Ben would say, we are cloud-first and thus strongly discourage users from deploying cockroachdb on systems shared between multiple users (or services) anyway. Trying to micro-optimize for multi-user, single-system deployments doesn't really gel with our product strategy.

[aaron-crl]

Do we have a functional need to create with 0664 or would 0660 work just as well for CRDB functions?

Limiting access to sensitive information is still valuable - even outside the multi-user system.

For example: If another service on the system has an arbitrary file read vulnerability but it is running under its own user account, limiting these permissions would limit the potential impact of such a vulnerability. Whereas in the current setup, an attacker could real CRDB sensitive information from any other compromised user access.

[knz]

Do we have a functional need to create with 0664 or would 0660 work just as well for CRDB functions?

I think it would work. Worth trying out

[robert-s-lee]

@a-entin for consideration for healthcheck