create a systemd service without write access to /etc/systemd/system

[dulh...@mailbox.org]

I need to create a postgresql@[db_service_name].service for systemd on remote hosts. Based on extremely limited access rights on such hosts (due to strict company security policies) the challenge I am facing is that the only way to do this manually is via

sudo systemctl edit --full postgresql@[db_service_name].service

This allows to edit a unitfile interactively which then is used to start the service.
I do not have any direct write access to /etc/systemd/system or anything else outside /opt on such remotes.

so, is there any way to get specific values into that unit file via ansible under such circumstances?

[Andy Smith]

Hi,

On Thu, Sep 01, 2022 at 07:15:42AM +0200, dulhaver via Ansible Project wrote:
> the challenge I am facing is that the only way to do this manually
> is via
>
> sudo systemctl edit --full postgresql@[db_service_name].service

If you can use sudo then can you not just do the equivalent of

sudo cp /some/temp/file /etc/systemd/system/whatever.service

?

How locked down exactly is your sudo access? I'd have thought that
if you can issue "sudo systemctl edit" then you can easily cook up
something that can give you arbitrary access, so this restriction
seems like more of an "honour system", i.e. a determined attacker
who realises they can do "sudo systemctl edit" will not be stopped.
So on that basis maybe they will allow "sudo cat …" also.

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

[Rowe, Walter P. (Fed)]

Nope. Ansible uses sudo to elevate privileges on Linux. If you don't have a service account that can sudo, you can't do this with ansible. Your service account is the "remote_user" that ansible uses to SSH into the machine. The sudoers file must grant this account sudo rights. 

It does not have to be passwordless sudo. You can provide a variable ansible_become_password that contains the sudo password. There are many ways to do that. The most secure way would be an ansible vault. This is essentially an encrypted vars file. You provide the vault secret when you run the playbook. On your command line you would do something like this.

$ ansible-playbook my_playbook.yml -e @my_vault.yml --ask-vault-pass

The @my_vault.yml tells ansible-playbook to source the my_vault.yml for its extra_vars. The --ask-vault-pass prompts you for the vault secret. Your my_vault.yml file would look like this:

---

ansible_become_password: "my sudo password"

If you use Ansible Tower you can provide the vault secret in an Ansible Vault Credential type. We use this method also for storing privileged Kerberos credentials that enables our playbooks to join machines to Active Directory.

Walter
--
Walter Rowe, Division Chief
Infrastructure Services, OISM
Mobile: 202.355.4123

-- 
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To view this discussion on the web visit https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fansible-project%2F1823518936.133081.1662009342899%2540office.mailbox.org&data=05%7C01%7Cwalter.rowe%40nist.gov%7C2c0b8a00151445d73e4508da8bd908fd%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637976061533248124%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XpM%2B9O9POGhoWj9dE9%2Bk%2Bc9Ub0TercGjG2e1oIXZBKo%3D&reserved=0.

[Hearn, Stan J.]

The sudo privileges granted to "remote_user" needs be to be limitless.   Execute ALL commands as ALL users.  One cannot restrict to executing a single binary like 'useradd' because it's running a module with a random name.

 

It's either all or nothing.

 

Regards,

Stan

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/F19F89B1-6C1B-4F50-B2AF-8681D60E408E%40nist.gov.

[Kevin Shumaker]

When confronted by a lack of privileges to be able to accomplish certain tasks given to me, I've usually resorted to creating a ticket with my 'resolution', and  escalating to the SysAdmins and let them 'deal' with the issue. (Usually limited access on specific servers). If they get enough tickets, the Manager or Director usually takes notice, and either grants specific access or transfers the responsibility to the SysAdmins. (What usually happens shortly  thereafter is it gets placed back in my lap, with needed privileges as they SysAdmins are already too busy, which is why it was placed in my lap to begin with...) Either resolution is a win.

[dulh...@mailbox.org]

 

system access is granted pretty specific (and pretty limited). The fear is not so much a hacker but our own staff should only be able to execute very specific commands (and creating anything in /etc not bein one of those for a member of the database team) he or she is supposed to execute.

 

 

@kevin.shumaker: thks, I was hoping to find away around playing such kind of pingpong, but it looks like there is none, so I'll have to play along.

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/ae6c0774-a100-443c-ba0c-ab638ffc7421n%40googlegroups.com.

[dulh...@mailbox.org]

 

I am wondering whether granted limited write access to the postgres user (who is the one executing that TASK) to only write files like postgresql.*.service inside /etc/systemd/system could be a solution. I guess using the template module would be the way to do this.

 

postgres@server> sudo -l looks like this exerpt

 

 

(root) NOPASSWD: /usr/bin/cat /var/log/messages, /usr/bin/zcat /var/log/messages-*, /usr/bin/systemctl restart
postgresql.service, /usr/bin/systemctl reload postgresql.service, /usr/bin/systemctl status postgresql.service,
/usr/bin/systemctl restart postgresql@*.service, !/usr/bin/systemctl restart postgresql@*..*,
!/usr/bin/systemctl restart postgresql@*[[\:blank\:]]*, /usr/bin/systemctl reload postgresql@*.service,
!/usr/bin/systemctl reload postgresql@*..*, !/usr/bin/systemctl reload postgresql@*[[\:blank\:]]*,
/usr/bin/systemctl status postgresql@*.service, !/usr/bin/systemctl status postgresql@*..*, !/usr/bin/systemctl
status postgresql@*[[\:blank\:]]*

 

so based on this I wonder whether this could be achived whether I could identify the local command executed by the template module in order to create the file on the remote. Or is that thinking down the wrong road?

 

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/F19F89B1-6C1B-4F50-B2AF-8681D60E408E%40nist.gov.

[dulh...@mailbox.org]

it has turned out that our entire approach creating the postgres service needs to be different and that the different approach provides an editable .env file.

So this was kind of a false alarm, sorry

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/165023126.27377.1662095842063%40office.mailbox.org.