[cap-talk] Confused Deputy, multiple authorities - Norm?
lists at notatla.org.uk
lists at notatla.org.uk
Wed Oct 25 03:56:53 CDT 2006
> I probably can't describe it crisply. I think of it as a case where
> the Deputy performs an operation that it truly wanted to take, but performs
> the operation using the wrong set of authorities (normally, because the
> default set of authorities are the wrong choice for this operation).
> Notably, this operation would have been safe to perform, if it had been
> performed using the correct set of authorities.
In the mid 1990s I used SGI's Irix (versions 5.x, 6.x) and remember
(mostly accurately I think) the following distasteful things about
their printing arrangements.
The lp command was setuid (to lp). The idea behind this was that the
command would do remote printing via remsh (as lp, to lp at some-server)
and had the authority to do this.
The result was that it opened your file as lp, rather than as you.
"lp myfile.txt" would fail if your file had mode 0600 (unreadable by lp)
and we worked round it with "lp < myfile.txt", at the expense of losing
useful titles on header pages and in lpstat output.
A corresponding error in the other direction would be if there was a file
owned by lp and not readable by the user - the user could read the file
indirectly by printing it. This is what I think is meant by "confused deputy".
(It was daft anyway because by default there was no password on the lp account
http://www.faqs.org/faqs/sgi/faq/security/section-3.html
and there are other ways to do remote printing.)
But in Unix if a program running as root does set euid to some user (as is often
advised for doing the user's file operations) it exposes itself to possible
problems with signals and ptrace().
Traditional systems aren't well-prepared to handle hostile data. They sometimes
admit this (in law 1)
http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx?mfr=true
but it needs to be broader because "executing a program" is not the only problem when your
web browser and word processor etc are interpreters "executing" files you didn't make. The
whole execution environment needs suitable arrangements for its authority. After much
reading on capabilities I still don't think I understand them but they do seem to be aiming at
the right target. Because you aren't going to get perfect programmers.
I say major defects in an OS for business use include:
- discretionary access control - and especially world-write
- lack of good and uniform delegation of pieces of control without entire control
(webservers to this team, backups to that, monitoring to another ...)
and I think capabilities have something to say on this too but I'm not sure what it is.
More information about the cap-talk
mailing list