Messages in this thread |  | | Date | Thu, 12 Dec 1996 20:59:26 +0000 (GMT) | From | The Deviant <> | Subject | Re: Proposal: restrict link(2) |
| |
-----BEGIN PGP SIGNED MESSAGE-----
On Thu, 12 Dec 1996, Thomas Koenig wrote:
> > The Deviant wrote: > > >Exactly. since /etc/passwd is root.root (or root.shadow, or whatever), > >anything linked to it (/tmp/foo in this example) is also owned root.root. > >As the original author of this thread should have observed before posting, > >a user may not chown something he to or from a user or group he does not > >belong to. This "crack" will not work. > > Uh, sure. Unless, that is, I can trick a root-privileged program into > chowning something in /tmp, for example. Can anybody say "xterm logging > bug"?
Thats not a kernel problem. Thats a userspace problem. xterm needs to be fixed, not the kernel.
> Alternatively, consider the possibilities when a root-privileged does an > open() on a file in /tmp. I feel much more secure when I know that this > CAN'T open any valuable configuration file.
If you don't want your machine to be hacked, and you're willing to sacrafice functionality, don't network it.
> Some programs use mktemp(3). The filenames generated are predictable. > Soft links are one way of exploiting this; hard links are another.
Then mktemp(3) needs to be fixed... A concept which I am all for. But again, this is userland, not kernel. If you want to go fix libc so that mktemp(3) doesn't produice predictable filenames, go right ahead. This would, IMHO, be a Good Thing. Its still not a kernel problem.
--Deviant PGP KeyID = E820F015 Fingerprint = 3D6AAB628E3DFAA9 F7D35736ABC56D39
Just once, I wish we would encounter an alien menace that wasn't immune to bullets. -- The Brigadier, "Dr. Who"
-----BEGIN PGP SIGNATURE----- Version: 2.6.2
iQEVAwUBMrBydDCdEh3oIPAVAQG3swf9E9n44gJ97b1Yrp1DE4lNPaekW3Uq22oI 1bYUcIJWh3Voz9f90TpjyaOd6k9+G+5btxr/Tb+zREMFH9t7Jp18ypX8fmD2DzwG M1y78QYs4LhSP5gOwlEpo0PAR0bzVqnT6akT9Jyz21oFkRjk2AjwwfXyd8f85zvZ Nzi4rys3rcm8Ss7/Uc6WNIoa2xVo0hY4dpGY0Q4iw+GJXdQVKnNSfjemzzDelMEh 5eWDDni4wR4Am2ysjrYGuubMrP3H54RE9IOsq3Vcp2GWS1e8lLvgxMwZJpGnnLpA KTUr9pNJMOK+akWqQnES1Q2yai5m2eNGw4rSy7tZ6tcwI5wi/Zv6Zw== =rqMZ -----END PGP SIGNATURE-----
|  |