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

"screen" is not hidden #2

Open
unixfox opened this issue Nov 3, 2016 · 7 comments
Open

"screen" is not hidden #2

unixfox opened this issue Nov 3, 2016 · 7 comments

Comments

@unixfox
Copy link
Collaborator

unixfox commented Nov 3, 2016

When I run the screen command, the owner of the machine (logged as root) can view the running command inside top/htop and can join the screen session.
I've the almost same behavior with tmux but the tmux running command isn't listed inside the "top"/"htop" command.

Is there a way to hide completely a screen/tmux session or does exist a multiplexer terminal program that doesn't allow other users to join the session?

@mempodippy
Copy link
Owner

mempodippy commented Nov 3, 2016

My assumption is that it would occur since the effective GID of the user is changed when using tmux or screen.
"uid=0(root) gid=729911652 egid=43(utmp) groups=43(utmp),0(root)" is the output that 'id' gives when in a screen session. And so, the effective GID of the screen/tmux process != the magic GID.
I'll see if there's a solution to this, but as far as I can tell this is outside of vlany's control.
I could prevent screen/tmux from changing the effective GID, but that might break some requirements of both terminals.
For now, avoid using screen or tmux. I'll see what I can do.

@mempodippy
Copy link
Owner

Problem fixed. The screen process is now completely hidden from process viewers.

@unixfox
Copy link
Collaborator Author

unixfox commented Aug 13, 2017

It's possible to list and enter into a screen created from the vlany shell.
Proof:
asciicast

@unixfox unixfox reopened this Aug 13, 2017
@mempodippy
Copy link
Owner

mempodippy commented Aug 13, 2017

Alright, so screen is responsible for making FIFOs, which are basically the screen sessions. The call that does this is mkfifo(). I can hook this and make the call automatically hide the new FIFO file with vlany's special extended attribute strings should the current user be the backdoor user. This shouldn't be a problem. But why would anyone kitting a box want to have resumable screen sessions in their backdoor?
I'll push a fix tomorrow. 😃

Discard everything I said that has a strike through it. FIFO files can't have extended attributes applied to them. But they can however, like everything else, have group IDs applied. I'll work something out.

@unixfox
Copy link
Collaborator Author

unixfox commented Aug 13, 2017

Screen is great for launching process in the background and being able to interact with it any time.
If you've a better alternative I'm interested.

@unixfox
Copy link
Collaborator Author

unixfox commented Aug 22, 2017

@mempodippy Thank you for trying :) but your modification isn't working:

[root@vlany:~/test]$ screen -S test
mkfifo /var/run/screen/S-root/10851.test failed

@mempodippy
Copy link
Owner

mempodippy commented Aug 23, 2017

I do actually have a mkfifo hook that redirects the fifo file and makes a symlink, but it doesn't work for some reason. It creates the fifo file in a different location and creates the symlink fine, but when trying to hide the link, mkfifo (or screen) throws an error. I'll push what I have right now and I'll add some commentary so that my intentions are somewhat clearer.
I think screen might be throwing the error because the new file isn't actually a fifo file.
Gimme a sec.
Edit: Hook commented and pushed. In the meantime, avoid using multiplexers or anything similar. Their behavior is a nuisance.

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

No branches or pull requests

2 participants