ITS translations: security problem?

[Brandon Allbery]

[Why the H*LL was this crossposted to comp.arch?!  EVERYTHING in unix.wizards
ends up crossposted there -- maybe they should be merged?!  ++bsa]

As quoted from <16008 at think.UUCP> by barmar at think.COM (Barry Margolin):
+---------------
| In article <9690 at tekecs.TEK.COM> andrew at frip.gwd.tek.com (Andrew Klossner) writes:
| >	  So you add s|^/bin/rm$|/user/me/bin/rm| to your
| >	translation list."
| >
| >What about the security implications?  Under Unix, I could use these
| >translations to spoof setuid programs, e.g., make my own /etc/passwd
| >then invoke /bin/su.
| 
| However, to answer your question about how this could be done in Unix,
| the answer is to not inherit translations in setuid processes.
+---------------

Probably a good idea anyway, but then you get into a very un-Unixy idea:
separate translations per-process, per-user-id, and per-system.  This would,
on the other hand, be more general than just suppressing translations for
setuid programs.

I don't think filename translations of this type are a good answer to the
original problem; too much rope for a user to hang (his/her/it)self with.
The generalized mount from the LAST time we discussed this still sounds best
to me; add a restriction that the mount must be on a directory writeable by
the user to close the security hole, which is otherwise the same as with
translations (mount .breakin /etc).  Possibly also the directory should be
empty, although this limits its usefulness over networks (NFS/RFS).  (Note
that the writeable-directory restriction would be too expensive to apply to
filename translations, but for the mount call it's cheap.)
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
       {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
KABOOM!!! Worf: "I think I'm sick." LaForge: "I'm sure half the ship knows it."
Newsgroups: comp.unix.wizards,comp.arch
Subject: Re: ITS translations: security problem?
References: <1495 at osiris.UUCP: <2126 at haddock.ISC.COM> <1497 at osiris.UUCP> <704 at PT.CS.CMU.EDU> <1424 at gumby.mips.COM> <9690 at tekecs.TEK.COM> <16008 at think.UUCP>
Reply-To: allbery at ncoast.UUCP (Brandon Allbery)
Followup-To: comp.unix.wizards
Distribution: 
Organization: Cleveland Public Access UN*X, Cleveland, Oh

As quoted from <16008 at think.UUCP> by barmar at think.COM (Barry Margolin):
+---------------
| In article <9690 at tekecs.TEK.COM> andrew at frip.gwd.tek.com (Andrew Klossner) writes:
| >	  So you add s|^/bin/rm$|/user/me/bin/rm| to your
| >	translation list."
| >
| >What about the security implications?  Under Unix, I could use these
| >translations to spoof setuid programs, e.g., make my own /etc/passwd
| >then invoke /bin/su.
| 
| However, to answer your question about how this could be done in Unix,
| the answer is to not inherit translations in setuid processes.
+---------------

Probably a good idea anyway, but then you get into a very un-Unixy idea:
separate translations per-process, per-user-id, and per-system.  This would,
on the other hand, be more general than just suppressing translations for
setuid programs.

I don't think filename translations of this type are a good answer to the
original problem; too much rope for a user to hang (his/her/it)self with.
The generalized mount from the LAST time we discussed this still sounds best
to me; add a restriction that the mount must be on a directory writeable by
the user to close the security hole, which is otherwise the same as with
translations (mount .breakin /etc).  Possibly also the directory should be
empty, although this limits its usefulness over networks (NFS/RFS).  (Note
that the writeable-directory restriction would be too expensive to apply to
filename translations, but for the mount call it's cheap.)
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
       {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
KABOOM!!! Worf: "I think I'm sick." LaForge: "I'm sure half the ship knows it."