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

Run the application as a non root user #20394

Closed
18 tasks done
agrare opened this issue Jul 29, 2020 · 12 comments
Closed
18 tasks done

Run the application as a non root user #20394

agrare opened this issue Jul 29, 2020 · 12 comments
Assignees
Milestone

Comments

@agrare
Copy link
Member

agrare commented Jul 29, 2020

A highly effective approach to mitigating security attacks by users via the API or UI is to run the application as an unprivileged user. This means that even if a vulnerability is exploited it is not possible to get root access to the machine.

Phases:

@kbrock
Copy link
Member

kbrock commented Feb 4, 2021

moved to OP

@agrare
Copy link
Member Author

agrare commented Feb 4, 2021

smartstate

mount block devices

Technically only RHV requires this, not all smartstate. In addition to reading raw block devices it has to mount nfs shares (also requires root)

@agrare
Copy link
Member Author

agrare commented Feb 4, 2021

We use file permissions for our DRb unix sockets in /tmp, if we end up with e.g. miq_server running as root we might need to create the socket as the same user the rest of the workers are running as

@chessbyte
Copy link
Member

If we are to support RHV SmartState, it may be cleaner to extract the mounting and reading into a separate service/worker with the appropriate privileges and expose an API for the caller to use. Not saying this is easy, but probably the right direction to isolate interfaces to mount.

@kbrock
Copy link
Member

kbrock commented Feb 5, 2021

I like adding a socket to communicate with the disk.

I'm hoping that we can come up with a solution that makes these parts of the product more container friendly.

@kbrock
Copy link
Member

kbrock commented Mar 3, 2021

I am moving this comment lower to not distract from the TODO list:

To work with containers, we have already defined the privileges needed to run our application. So the job ahead is mostly porting the Kubernetes/OpenShift privileges to SELinux. The MiqServer process running on the VMware appliance also acts as a distributed orchestrator, so this requires adding systemd privileges similar to the ones defined in the Kubernetes privilege profile.

Since the webapp is the closest to the end users, it is most vulnerable to attacks and needs to be the most restricted. All privileges required by the webapp are also required by the other roles. It is possible that as we discover more, we may be able to merge some of the roles.

Our app has 4 roles with different required privileges:

  • webapp (and all others)
    • read v2_key
    • write to logs
    • read database config and settings
  • orchestrator
    • enable and disable services.
  • smartstate
    • mount block devices
  • admin
    • appliance_console
    • change configuration files
    • install rpms
    • ssh to the box

@Fryguy Fryguy added this to the Morphy milestone Mar 18, 2021
@Fryguy
Copy link
Member

Fryguy commented Jun 24, 2021

I know it's briefly mentioned in #21295 for the database.yml part, but ha-admin also seems to write to the evm.log, which probably affects your logger problem? I'd be ok if that became a dedicated log file:

ManageIQ::PostgresHaAdmin.logger = Vmdb.logger

@Fryguy Fryguy changed the title Run the application as a non-root user Run the application as a non root user Jun 24, 2021
@Fryguy
Copy link
Member

Fryguy commented Jun 24, 2021

Changed the title slightly so I can search the word "root" on the projects board 😆

@agrare
Copy link
Member Author

agrare commented Feb 16, 2022

We're so close to closing this out, propose that we move "Stop Logging to Files" out of this issue, we already resolved the "workers have to run as root in order to write to log files" with having these owned by manageiq:manageiq with 0660

We already have a separate issue for #21004 we can add that to the roadmap targeting Oparin

@chessbyte
Copy link
Member

@agrare I can move that out. What about the 2 items under SSL database as non-root? If these are close, I would like to get them across the finish line, otherwise will push to Oparin.

@agrare
Copy link
Member Author

agrare commented Feb 16, 2022

@chessbyte I'm not sure about those, we did have to revert ManageIQ/manageiq-appliance#341 since it was causing us to not be able to connect to the database. Maybe @kbrock can correct me but that section looks further than closer to being done

@chessbyte
Copy link
Member

Split off SSL Database as non-Root to #21722

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Najdorf
Development

No branches or pull requests

5 participants