[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Policy on file permissions


"They should not be
made unreadable (modes like 4711 or 2711 or even 4111); doing so
achieves no extra security, because anyone can find the binary in the
freely available Debian package--it is merely inconvenient. For the same
reason you should not restrict read or execute permissions on
non-set-id executables."

Now, please see the message I've attached from Chris Evans, sent to the
security-audit mailing list.

I'm posting this here because I really don't know anything about what
he's talking about, and I'm hoping some of you will.  Would his
statement regarding file permissions constitute a reasonable argument
for changing our policy?

Please speak up with your opinions.  :)  Thanks.

--- Begin Message ---
On Fri, 21 Jul 2000, Pavel Kankovsky wrote:

> For instance, if Chris' telnetd patch is used, and all telnetd instances
> run under the same uid, a compromised telnetd process can ptrace() (at
> least unless some setcap() magic or something similar is used) other
> instances and manipulate with them (read passwords, insert commands).


The process starts as root and then (before any potentially compromisable
network parsing) does setuid() to another user.

If you switch uids but don't do an exec(), this leaves current->dumpable =
0 in the kernel. Result: the unprivileged telnetd processes cannot
ptrace() each other.

Speaking of ptrace(), though, the chroot()'ed telnetd process definitely
should run under its own uid and not something like nobody. Otherwise a
compromised chroot()'ed nobody process can ptrace() a nobody process[1]
which isn't chroot()ed, and so escape the jail. I'm just guessing, but I
bet the kernel doesn't spot this case => kernel bug.


[1] Although note that I'm trying to ensure most nobody process, and in
fact daemons in general, run with current->dumpable = 0. This can be
accomplished by using binaries with permissions -rwx--x--x

--- End Message ---

Reply to: