Linux Debian support - Re: Setgid on home directory, strange result (permissions, etc.)

Author

Re: Setgid on home directory, strange result (permissions, etc.)

Michael Paoli

2006-03-14, 2:46 am

john wrote:
> post. This exercise started out with me being curious about why my home
> directory had permissions 755 on it. I'm the only one using the machine
> so it' pretty much an academic exercise, but surely it's not right to have
> those permissions on everyone's home directory, is it? Is everyone's home
> directory world readable by design?

First of all, there are Debian specific ways of changing these defaults
- e.g. the permissions used creating a user's home directory, user's
default
umask, etc., e.g.:
login.defs(5)
adduser.conf(5)

Secondly, 755 permissions on a home directory doesn't necessarily make
the contents of the home directory insecure. It will allow reading of
the names of items (links) within the directory, and the ability to
stat(2)/lstat(2) them, but any additional access granted to items
within
the 755 directory depends upon the permissions of those items. If the
permissions are more stringent than 755, everyone will pretty much be
locked out of the directory - e.g. if read is denied, they can't get
the
names of the stuff in the directory, if "execute" (x) permission is
denied, they can't cd into the directory, and they can't access or stat
any items within the directory.

> Permissions seem to be somewhat confusing. For example, the permissions
> on the /sbin directory are 755 and the files within /sbin are also 755,
> except for a few that are 777. Seems really strange. I can change into
> the subdirectory but I can't run "shutdown" as a normal user - it says
> "you have to be root to do that". Fine. If I run modprobe -r somedriver
> (not being used, according to lsmod) modprobe objects but doesn't tell me
> why. If these binaries are not to be run by ordinary users, why are the
> permissions set the way they are? Why not just set them to 700 in every
> case? Why hardcode the requirement to be root right into the executable
> (which seems like it might be prone to error), and then set the file
> permissions to 755 ?? Or why take care to exclude sbin from the
> path of the normal user, then let him wander around in there?

This is a pretty typical scenario, e.g.:
drwxr-xr-x 2 root root 5120 Jan 15 11:29 /sbin
-rwxr-xr-x 1 root root 58348 Apr 22 2004 /sbin/ifconfig
Regular users can run ifconfig (useful if they want to examine the
configuration of an interface), but they generally wouldn't be able to
use ifconfig to change a configuration. Stuff like this tends to get
tucked away in /sbin and /usr/sbin as those are considered *S*ystem
binaries/programs. That doesn't mean users can never do anything with
them, but most of the time the casual user won't be interested in them.

Denying read and/or execute on such commonly available programs often
does little to nothing regarding security - e.g. if user can snag a
copy
of the program from elsewhere, or otherwise create a duplicate, then
they can generally read and execute that program with whatever
privileges their ID has (or lacks).

The requirement to be superuser (UID 0, typically root) isn't
necessarily hard coded into the applications/programs. In many cases
they attempt the privileged operation(s), and if run by a UID that
doesn't have sufficient privilege, various things the program attempts
will fail - and the better behaved programs will generally complain
fairly clearly about what couldn't be done or what failed - and perhaps
even why.
The 777 stuff you're seeing in /sbin is probably just symbolic links -
the permissions of symbolic links don't matter (except perhaps for
cosmetic purposes) - in the case of a symbolic link, what (if anything)
the symbolic link eventually resolves to is what matters.
shutdown(8) (e.g. see: /etc/shutdown.allow)
http://www.pathname.com/fhs/