Are the containers now restricting the AUDIT_* syscalls?
philtroinr
PROOP

22 days ago

We have been running a jump host on our infrastructure in order to securely connect to node debuggers from extra locations. The jump host runs openssh on top of Kali linux, exposes the SSH port via TCP forwarding (fully locked down, only pubkey authentication allowed) and allows port forwarding to the node.js inspector ports on the internal network.

Up until yesterday, everything was working fine.

When the container was redeployed yesterday (April 29), we started seeing new errors related to audit syscalls emitted by sshd:

https://railway.com/project/7ff52821-b7d2-459c-bff8-3f070394a82b/service/953703e6-bf1a-40aa-b6a7-d665af24303a?environmentId=ce6356bb-eb79-4e3a-ba2c-3349408bb5e5&id=952c794e-5b7d-4ea2-aad3-220ba606ce46&filter=audit#deploy

debug1: audit_event: unhandled event 12
linux_audit_write_entry failed: Operation not permitted

Did the railway team lock down the audit syscalls in containers yesterday?

This seems very similar to https://bugzilla.redhat.com/show%5Fbug.cgi?id=1923728

Thanks,

Phil.

Solved

4 Replies

Status changed to Awaiting Railway Response Railway 22 days ago


22 days ago

Yes we did.


Status changed to Awaiting User Response Railway 22 days ago


philtroinr
PROOP

21 days ago

Thank you for confirming @brody.

Are these kind of low-level changes announced anywhere? https://railway.com/changelog doesn't say anything...


Status changed to Awaiting Railway Response Railway 21 days ago


21 days ago

These types of low-level security hardening changes aren't published to the changelog.


Status changed to Awaiting User Response Railway 21 days ago


philtroinr
PROOP

21 days ago

OK, good to know, thank you.


Status changed to Awaiting Railway Response Railway 21 days ago


Status changed to Solved philtroinr 21 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...