Users can see other's opened sockets through /proc

[gmcclins]

I have been doing some looking around checking various things to make sure permissions were as they should be, more in regards to leaking user info or world readable files that may contain sensitive info. Still doing more, but I figured I would post this now (really should have a few days ago). Some issues that I found were resolved that day when posted in irc so no need to mention any further, however the following remain.

netstat -antp
netstat -anup

Or any other netstat command that I didn't think of that should require sudo privileges does not

This of course leads to the leak of users address information as well as showing some open ports on the hashbang server that may have otherwise went unknown that could, possibly be used as information gathering for an attack.

I have also discovered that some logs in /var/log are readable

• -rw-r--r--. 1 root adm 540750 Mar 3 01:28 cloud-init.log
• -rw-r--r--. 1 root root 20486 Mar 3 01:28 cloud-init-output.log

as well as others.

This also poses the question, should I as a regular user, even have access to the /var/log directory

[gmcclins]

If this helps I used strace on my debian jessie server first without sudo and then with sudo. I also did a strace on hashbang (obviously without sudo). All gists have been marked as private and I can delete upon request, if needed.

• https://gist.github.com/geoffmcc/bfdc69a2fbe2bea3672a — strace on local server with no sudo
• https://gist.github.com/geoffmcc/31fbc27220ae4c2fdb52 — strace on local server with sudo
• https://gist.github.com/geoffmcc/eaa168577ae9e863026c — strace on hashbang with no sudo

Looking through them, the first thing I noticed was my strace on my local machine has a bunch of permission denied errors, an example follows.

openat(AT_FDCWD, "/proc/1/fd", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)

Also, strace on my local server with sudo looks very similar to strace of hashbang.

I thought maybe netstat is suid root on hashbang, but it does not appear to be the case.

(Edited by Ryan: formatting)

[daurnimator]

however the following remain.

netstat -antp
netstat -anup

Or any other netstat command that I didn't think of that should require sudo privileges does not

These just use /proc/net/tcp and /proc/net/udp under the hood. Protecting access to them probably needs something as invasive as grsec.... Unless perhaps we can just change permissions with a udev rule?

[daurnimator]

I have also discovered that some logs in /var/log are readable

-rw-r--r--. 1 root adm 540750 Mar 3 01:28 cloud-init.log
-rw-r--r--. 1 root root 20486 Mar 3 01:28 cloud-init-output.log
as well as others.

I had a look through those and nothing seems to be delicate.
I'm happy leaving these readable.

This also poses the question, should I as a regular user, even have access to the /var/log directory

As a service that hopes to teach sysadmins, we want to have as much visible about the system and how it works as possible. We only hide security sensitive info (i.e. keys+passwords) and information leaks about other user's private data.
Where to draw the line about 'private data' and 'public data' is a bit unsettled, and has mainly been dictated by what is possible/easy.

[daurnimator]

If this helps I used strace on my debian jessie server first without sudo and then with sudo. I also did a strace on hashbang (obviously without sudo). All gists have been marked as private and I can delete upon request, if needed.

*https://gist.github.com/geoffmcc/bfdc69a2fbe2bea3672a -- strace on local server with no sudo
*https://gist.github.com/geoffmcc/31fbc27220ae4c2fdb52 -- strace on local server with sudo
*https://gist.github.com/geoffmcc/eaa168577ae9e863026c -- strace on hashbang with no sudo

Looking through them, the first thing I noticed was my strace on my local machine has a bunch of permission denied errors, an example follows.

openat(AT_FDCWD, "/proc/1/fd", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied)

Also, strace on my local server with sudo looks very similar to strace of hashbang.

I thought maybe netstat is suid root on hashbang, but it does not appear to be the case.

There is nothing to worry about here, you are only seeing information about your own processes.
We accomplish this with the 'hidepid' option when mounting /proc

[gmcclins]

I'm confused. There is nothing to worry about what? I am looking at a list of ip addresses of other users that are currently connected both in tcp and tcp6. Most are connected to port 6697 ( i assume irc) but some on 57790, 8333, 35481 ...

[daurnimator]

I'm confused. There is nothing to worry about what? I am looking at a list of ip addresses of other users

That is from /proc/net/tcp. which I addressed in my first comment reply.

[gmcclins]

Okay. I was just concerned as if I run on my local server without sudo non-owned process info
will not be shown, and I thought you agreed this was an issue in irc the other night.

Should I close issue?

[daurnimator]

Okay. I was just concerned as if I run on my local server without sudo non-owned process info
will not be shown, and I thought you agreed this was an issue in irc the other night.

You can just run cat /proc/net/tcp on any server.
It is a small issue (you can actually brute force it!), but a hard one to fix.

[RyanSquared]

Is this resolved as a minor issue? We are a public service; in my opinion, if you don't want something you're running shown, don't run it using our service. Should we close this?

[daurnimator]

We are a public service; in my opinion, if you don't want something you're running shown, don't run it using our service.

That's not fair at all.
I'd expect privacy from everyone except admins when using a shell service

[daveloyall]

What's the difference between a "shell service" and "shared shell service"?

What's the difference between renting a one-bedroom apartment and renting one room in a big house?

Having some visibility into the activities of peers is both positive and negative.

[KellerFuchs]

@ChickenNuggers I think we should try, as much as possible, to provide reasonable levels of privacy.

In that specific case, I'm unsure what to do: it seems there is no simple way to prevent users from learning about other users' connections.
Perhaps the PaX/GrSec patches have something about that. Will check.

[KellerFuchs]

Seems that GrSec's GRKERNSEC_PROC_USER does what we want.

On the other hand, that would mean maintaining a custom kernel package for our own use.

[KellerFuchs]

Ping?