Your message dated Sun, 11 Oct 2009 17:15:35 +0100
with message-id <20091011161535.ga30...@reptile.pseudorandom.co.uk>
and subject line Re: links2: Links chown, overwrites root owned links.cfg
has caused the Debian Bug report #536633,
regarding links2: Links chown, overwrites root owned links.cfg
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
536633: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536633
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: links2
Version: 2.1pre37-1.1
Severity: critical
Justification: root security hole
Tags: security
*** Please type your report below this line ***
I chown links.cfg in users .links2 directory to root:root. I set up
proxy to 127.0.0.1:8080 for filtering. I set permisions on links.cfg to
-for example- 100600. When a user changes proxy settings by the links2
menu options, the links.cfg file ownership changes to the user and
permissions are also overewritten.
-- System Information:
Debian Release: 5.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
--- End Message ---
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, 11 Jul 2009 at 14:21:22 -0700, llew wrote:
> I chown links.cfg in users .links2 directory to root:root. I set up
> proxy to 127.0.0.1:8080 for filtering. I set permisions on links.cfg to
> -for example- 100600. When a user changes proxy settings by the links2
> menu options, the links.cfg file ownership changes to the user and
> permissions are also overewritten.
This isn't links2's fault; you're misunderstanding how Unix permissions work.
Making a file unwriteable by a user prevents that user from writing to the
file directly, but it does not prevent them from deleting it, or from replacing
it with another file by renaming over the top.
This is because the ability to rename and delete is governed by the permissions
of the directory, not the file (so it's the permissions of ~/.links2 that
matter).
The rename-over-the-top trick also provides much better robustness, which is
why most programs use it for their configuration (it means that if the
computer loses power at any stage of the overwrite process, links.cfg always
ends up with either its old contents, or its new contents - never a
half-written, corrupted version of the new contents, which is what could
happen if it just opened the file for writing and wrote out the new contents).
links2 is unprivileged, so it couldn't chown/chmod root-owned files even if
it wanted to; in this case it can replace one, though.
An example shell session to demonstrate what's happening:
> s...@reptile:~$ mkdir .links2
> s...@reptile:~$ echo "before" > .links2/links.cfg
> s...@reptile:~$ sudo chown root:root .links2/links.cfg
> s...@reptile:~$ sudo chmod 0600 .links2/links.cfg
> s...@reptile:~$ ls -ld ~ ~/.links2 ~/.links2/links.cfg
> drwxr-x--x 135 smcv smcv 36864 2009-10-11 16:56 /home/smcv
> drwxr-xr-x 2 smcv smcv 4096 2009-10-11 16:56 /home/smcv/.links2
> -rw------- 1 root root 7 2009-10-11 16:56 /home/smcv/.links2/links.cfg
> s...@reptile:~$ echo "this won't work" > .links2/links.cfg
> bash: .links2/links.cfg: Permission denied
> s...@reptile:~$ echo "but this will" > .links2/tmp
> s...@reptile:~$ mv .links2/tmp .links2/links.cfg
> mv: try to overwrite `.links2/links.cfg', overriding mode 0600 (rw-------)? y
> s...@reptile:~$ cat .links2/links.cfg
> but this will
(Note that apart from the two calls to sudo at the beginning, I'm not using
any special privileges here.)
If you want to prevent a user from overwriting their ~/.links2/links.cfg,
it is not sufficient to make that file owned by root; you'd also have to
change the ownership of .links2 (so they couldn't rename a file over the top
of links.cfg), and of their home directory (so they couldn't move .links2
out of the way and create a new one).
(It's also unlikely to be useful to chmod links.cfg to 0600, as you say you
did - if you do that, the user's links2 won't be able to *read* it, so it will
probably fall back to its built-in defaults, which won't include the proxy
setting that you wanted.)
Simon
-----BEGIN PGP SIGNATURE-----
iQIVAwUBStIEn03o/ypjx8yQAQiUHQ/+IlkRBGLzLpZ3DdmOROjoGWC6Jd0Jl/zh
99e/YI6PzkWPvkp6sD3VfbtnWbNi/Vpmi6AAdedc8Cwu2xxCCV0ss/Wfyivf5wJ1
RSZcrKhpxQZFUEsl/2wstluQt4uUoLsxgwL6tLBTNeFRCbeo3SHPrTwzHeeFp//p
pP3zdGzrFCAjn7VbL2bLCFQQBQ8jbegz8bGf7jqCz3tf3xKr2dMfp7AmEsfTL6bl
qAQWUxnDLypFlom+fBjFWMwVd+KSiEL14XlEZ6OhoRAsQxM+OkZD2942HyT88FQx
6baojWe/Dt5eK9hXrmX1ViyWpB65FmNOQjdnscrWDa3yNClW6/+M/eWowr/Wx/oJ
K5lCVnf5U+8dIk3bgovlPCZljwu9Xr/MKneJq306yHnNypgsL8mcuEIe3WtIBnfh
+LKsteRg8nLZrWyjZLy13CzbJ4XUMmWzvEVdedOp62YJR6wl5hoI+B2y3w3P/VsR
3dEBrqNVrel8jkPv+rzi4EOCj7bmKtYENs+kwgd011PBrAJKNHMlFbec9ZnmB5qI
GszZMrcFQcL5dnSRw8VZ54mW/Iv+CeowGGop0fDVl2Btc+z5ft5olGKrDUm2jF9h
yFbGBCRg4reHjxZvfbU33pbvqh7mGGDPoNvdZ5H/57lZ3SQx786S5LJWmagQsmIN
Al0ZvUmw0FM=
=WbmL
-----END PGP SIGNATURE-----
--- End Message ---
