search

hashbang / shell-etc

/etc directory from our shell servers, managed via etckeeper
MIT License
23 stars 18 forks source link

Prevent listing of users by inspection of /dev/pts #1

Closed daurnimator closed 9 years ago

daurnimator commented 9 years ago

I don't think there's an easy way to do this.

@doverride suggests an selinux policy that prevents stat for /dev/pts/[0-9]* nodes. @deleriux2, opinions?

ghost commented 9 years ago

Last time I checked our current plan was to do something with selinux. @lrvick - can you confirm this?

ghost commented 9 years ago

On Sat, May 02, 2015 at 06:24:29PM -0700, Alissa wrote:

Last time I checked our current plan was to do something with selinux. @lrvick - can you confirm this?

In reference to this discussion i set out to try it using my own security policy (focussing on ptys rather than ttys).

In practice it works for me to some extend but some of the issues i noticed with my configuration are:

  1. sshd logs an error message about not being able to access the pty when the user logs in this error can be ignored, and the user can still log in and use the pty

  2. some coreutils rely on the ability to get attributes of ptys cat does not work becuase it cannot get the attributes of the currently connected pty

    the ironic thing is that tac does not have this requirement and thus tac works fine without being able to get attributes of the pty node

The above issues could in theory be hacked around but it would be very, very, expensive Every user that maintains a pty with need its own pty node type, so that the user can only get the attributes of its own pty node

Reply to this email directly or view it on GitHub: https://github.com/hashbang/shell-etc/issues/1#issuecomment-98423456

02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788 Dominick Grift

lrvick commented 9 years ago

Honestly I don't see the ability to list users as an issue. A list of usernames is kind of meaningless and it also exists in the IRC channel. A lot of hackery without any reduced attack surface.

Closing this. If someone has a good explanation for why this is a mistake, please reopen with your thoughts and a proposed implementation