[ 
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363732#comment-17363732
 ] 

Ekaterina Dimitrova edited comment on CASSANDRA-16669 at 6/15/21, 3:55 PM:
---------------------------------------------------------------------------

Thank you all for your work!

For visibility and the sake of completeness:
 * There is a failure in the Jenkins devbranch run which is because the branch 
with the patch was not rebased so the 
[patch|https://github.com/apache/cassandra/commit/a0af091a5cbceeaa2b8f724b1790b61ef512b033]
 for which the failing test was created was missing. No new failures introduced 
by this patch. The post-commit is still running but the cqlsh tests are already 
[successfully 
completed|https://jenkins-cm4.apache.org/blue/organizations/jenkins/Cassandra-4.0.0/detail/Cassandra-4.0.0/27/pipeline].
 *  
And my feedback would be:
 
{quote} - Add a test case for {{CREATE /*password*/ ROLE bla bla}} which would 
be a way to bypass
 - In the future move to lexer/parser level obfuscation

 - You can only hack the thing with useless stmnts like {{ALTER ROLE 
alicepassword...}} that lead nowhere{quote}
These cases are covered in the latest patch as the patch is simple and drastic 
at this point until we work on the mentioned improvement for 4.0.1, It simply 
takes the DCL statement as a String and checks for password substring (upper 
case, mixed case, and lower case covered) and then obfuscates everything after 
it; non-valid statements are also covered which is visible from the test added 
by Vinay.


was (Author: e.dimitrova):
Thank you all for your work!

For visibility and the sake of completeness:
 * There is a failure in the Jenkins devbranch run which is because the branch 
with the patch was not rebased so the 
[patch|https://github.com/apache/cassandra/commit/a0af091a5cbceeaa2b8f724b1790b61ef512b033]
 for which the failing test was created was missing. No new failures introduced 
by this patch. The post-commit is still running but the cqlsh tests are already 
[successfully 
completed|https://jenkins-cm4.apache.org/blue/organizations/jenkins/Cassandra-4.0.0/detail/Cassandra-4.0.0/27/pipeline].
 * 
{quote}{quote}And my feedback would be:
{quote} - Add a test case for {{CREATE /*password*/ ROLE bla bla}} which would 
be a way to bypass
 - In the future move to lexer/parser level obfuscation

 - You can only hack the thing with useless stmnts like {{ALTER ROLE 
alicepassword...}} that lead nowhere{quote}
These cases are covered in the latest patch as the patch is simple and drastic 
at this point until we work on the mentioned improvement for 4.0.1, It simply 
takes the DCL statement as a String and checks for password substring (upper 
case, mixed case, and lower case covered) and then obfuscates everything after 
it. 

> 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: 6h 10m
>  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

Reply via email to