[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17360888#comment-17360888
]
Stefan Miklosovic commented on CASSANDRA-16669:
-----------------------------------------------
Hi [~e.dimitrova]
* we decided on not providing a user any possibility to not obfuscated
passwords. We do not see any use case behind that. Why would you want to have
them in plain text in the first place?
* yes, still WIP be we were about to close the last bits but we found more
issues
This batch issue is rather complicated, it also leaks stuff like this:
{code:java}
BEGIN BATCH
CREATE ROLE alice WITH PASSWORD = 'alice123' and LOGIN = true;
CREATE ROLE alice2 WITH PASSWORD = 'alice2123' and LOGIN = true;
APPLY BATCH;{code}
The entry, currently, looks like:
{code:java}
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:56698|timestamp:1623322819632|type:REQUEST_FAILURE|category:ERROR|operation:BEGIN
BATCH
CREATE ROLE alice WITH PASSWORD = 'alice123' and LOGIN = true;
CREATE ROLE alice2 WITH PASSWORD = '*******' and LOGIN = true;
APPLY BATCH;; line 2:0 mismatched input 'CREATE' expecting K_APPLY (BEGIN
BATCH[CREATE]...){code}
I started to fix this but that is more complicated than it looks so I am not
fixing it as of now.
* I added it to my commits
* thinking more about it, we do not need an interface tbh, I was thinking we
do but it is not necessary, if we ever needed that, we might just create one
afterwards so we should return to simple impl, sorry for the mess.
* I addressed your issues
The problem with adding a test for failing request like that is that I can not
receive it in the tests of AuditAuthLoggerTest, if I want to do something like
this:
{code:java}
@Test
public void testREQUEST_FAILUREAuditing()
{
createTestRole();
String cql = "BEGIN BATCH \n" +
" CREATE ROLE alice WITH PASSWORD = 'alice123' and LOGIN =
true; \n" +
"APPLY BATCH";
executeWithCredentials(Arrays.asList(cql), CASS_USER, CASS_PW,
AuditLogEntryType.REQUEST_FAILURE);
assertTrue(getInMemAuditLogger().size() > 0);
AuditLogEntry logEntry = getInMemAuditLogger().poll();
assertLogEntry(logEntry, AuditLogEntryType.REQUEST_FAILURE, cql, CASS_USER);
}
{code}
the method "executeWithCredentials" will fails as such so the test will never
proceed because the underlying driver evaluates this as a failure and it throws
an exception and whole test fails so I think it is enough to test this
empirically of you do not have any idea how to actually solve this. We might
add a test which tests the obfuscator though, there is not any problem with
that.
[~sumanth.pasupuleti] I have put these things together here
[https://github.com/instaclustr/cassandra/tree/CASSANDRA-16669-queryevents]
I do not know why but I am not able to create a pull request against your
branch anymore.
> Password obfuscation for DCL audit log statements
> -------------------------------------------------
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
> Reporter: Vinay Chella
> Assignee: Sumanth Pasupuleti
> Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
