Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
joshuaclayton opened this issue Mar 31, 2023 · 7 comments · May be fixed by #101

Comments

@joshuaclayton
Copy link

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
Copy link
Member

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
Copy link
Contributor

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.

@ghiculescu ghiculescu linked a pull request Feb 14, 2024 that will close this issue
@jorgemanrubia
Copy link
Member

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

@shouichi
Copy link

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
Copy link
Contributor

@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
Copy link
Member

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

@geoffharcourt
Copy link

geoffharcourt commented Apr 10, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants