`rails console --sandbox` allows for untracked read-only access to the database, including decryption of values

[joshuaclayton]

As the name suggests, storing console session data in the primary database results in the session record being rolled back in a transaction when running rails console --sandbox once it terminates.

While I'm not sure there's an actual "fix" to this behavior (it seems to be working as intended), I'd be interested to understand if the team would find an update to the README documenting this useful. I'd be happy to add a line or two about this if so.

[jorgemanrubia]

Good catch, thanks for reporting @joshuaclayton. I'm not sure what's the right solution here, but a note in the README is totally pertinent. Thanks!

[ghiculescu]

This seems like a big risk to me. Would you consider disabling the sandbox option when this gem is present?

You can use config.disable_sandbox for this.

[jorgemanrubia]

That's a good idea @ghiculescu. I'll be happy to merge a PR that disables the sandbox option when console1984 is enabled.

[shouichi]

Can we explore other directions (e.g., saving audit logs in another database)? To avoid accidental destruction, I always use sandbox mode first to check if commands work as expected.

[ghiculescu]

@jorgemanrubia #101

I can make it optional if you prefer but IMO it's better to be strict here and then loosen it up later if other options are added.

[jorgemanrubia]

I think optional but disabled by default is a sensible approach here @ghiculescu.

[geoffharcourt]

We've been using another database to store our console access with some success:

class Console1984Record < ActiveRecord::Base
  self.abstract_class = true
  self.belongs_to_required_by_default = false

  connects_to database: { writing: :console_access, reading: :console_access }
end

In config/application.rb:

config.console1984.base_record_class = "::Console1984Record"

The user that connects to that database can insert and can update sensitive_access_id but can't delete records. It's certainly not 100% tamper-proof, but we're also broadcasting console access via other means as some extra insurance.