[arch-general] Why are CA certifcates writable for every user?
Hello!
When I'm doing "cd /etc/ssl/certs/ && ls -al" I see something like this:
[...]
lrwxrwxrwx 1 root root 102 21. Dez 17:56
Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem ->
../../ca-certificates/extracted/cadir/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
[...]
All certificates are publicly writable.
I never set chmod to 777 on this directory and I see a great security
lack here.
Any program could inject its own certificate there, you should know this
isn't good ;)
Tell me whether this is just an issue on my own system or a general issue.
Marcel Kleinfeller
On 05/02/15 02:12 PM, Marcel Kleinfeller wrote:
Hello!
When I'm doing "cd /etc/ssl/certs/ && ls -al" I see something like this:
[...] lrwxrwxrwx 1 root root 102 21. Dez 17:56 Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem -> ../../ca-certificates/extracted/cadir/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
[...]
All certificates are publicly writable.
I never set chmod to 777 on this directory and I see a great security lack here. Any program could inject its own certificate there, you should know this isn't good ;)
Tell me whether this is just an issue on my own system or a general issue.
Marcel Kleinfeller
It's not an issue. It's a symlink. The permissions on the directory and the target are what matters.
Symlinks often (always?) show as 777 permissions. If you look at the actual file that it links to, you'll see the permissions are fine: [darose@daroseneo ~]$ ls -l /etc/ca-certificates/extracted/cadir/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem -r--r--r-- 1 root root 1602 Dec 22 09:54 /etc/ca-certificates/extracted/cadir/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem DR On 02/05/2015 02:12 PM, Marcel Kleinfeller wrote:
Hello!
When I'm doing "cd /etc/ssl/certs/ && ls -al" I see something like this:
[...] lrwxrwxrwx 1 root root 102 21. Dez 17:56 Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem -> ../../ca-certificates/extracted/cadir/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
[...]
All certificates are publicly writable.
I never set chmod to 777 on this directory and I see a great security lack here. Any program could inject its own certificate there, you should know this isn't good ;)
Tell me whether this is just an issue on my own system or a general issue.
Marcel Kleinfeller
Hi
On Thu, Feb 5, 2015 at 11:15 AM, David Rosenstrauch
Symlinks often (always?) show as 777 permissions.
Linux manpage for symlinks states http://man7.org/linux/man-pages/man7/symlink.7.html On Linux, the permissions of a symbolic link are not used in any operations; the permissions are always 0777 (read, write, and execute for all user categories), and can't be changed.
On Thu, 05 Feb 2015 20:12:31 +0100 Marcel Kleinfeller
[...] lrwxrwxrwx 1 root root 102 21. Dez 17:56 Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem -> ../../ca-certificates/extracted/cadir/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem [...]
Those are symbolic links, as designated by the 'l' prefix in the permissions. Symlinks in ls always show as having 777 permissions; their actual permissions are those of the target. Regards, ~Celti
On 05/02/15 19:20, Patrick Burroughs (Celti) wrote:
their actual permissions are those of the target.
From what I understand (and tests I've done, and discussions on arch channels on IRC) their actual permissions are inherited from the directory they are in AND from the permissions of a target. Actions that act on the target always inherit target permissions (read, write and execute). Actions that act on the link, however, always inherit the directory permissions (delete and move). This can be tested by symlinking a file from another user's home directory (which will obviously have to be done as root. The file should by default have 600 permissions and should be owned by that user and his group). Renaming and deletion of the symlink will be allowed, but attempting to read, write or execute the file will depend on the group/others permissions of the file. The Wikipedia article [1] on symbolic links basically seems to say something along these lines, but not entirely correct. However, that entire sections lacks a lot of citations and should really have a few more than one [citation needed] tag. [1] https://en.wikipedia.org/wiki/Symbolic_link#Storage_of_symbolic_links -- Tomasz Kramkowski E-Mail: tk@the-tk.com PGP: 6FCE87503AAF42AB3BF4 94FE40B037BA0A5B8680
On 02/06/2015 01:27 AM, Tomasz Kramkowski wrote:
On 05/02/15 19:20, Patrick Burroughs (Celti) wrote:
their actual permissions are those of the target.
From what I understand (and tests I've done, and discussions on arch channels on IRC) their actual permissions are inherited from the directory they are in AND from the permissions of a target.
Actions that act on the target always inherit target permissions (read, write and execute). Actions that act on the link, however, always inherit the directory permissions (delete and move).
Delete and move always depend on the (parent) directory permission, whether you operate on a symlink, a file or a subdirectory.
This can be tested by symlinking a file from another user's home directory (which will obviously have to be done as root.
Actually, this does not need root. You can even create a symlink to a non-existing file if you want. Actually *accessing* the symlink is another matter of course. Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
On 06/02/15 18:50, "Jérôme M. Berger" wrote:
Actually, this does not need root. You can even create a symlink to a non-existing file if you want. Actually *accessing* the symlink is another matter of course.
Yeah, now I think about it, saying that you can delete / move the symlink based on directory permissions and then saying that you need root for creation doesn't quite check out. You're right. Creation, deletion and moving (deletion then creation?) of a symlink is entirely dependant on the directory it is stored in. But actions like reading, writing and executing which act on the actual linked file depend on the permissions of the actual file linked to. (And it's needless to say that the file permissions of the symlink itself (777) can be completely ignored.) -- Tomasz Kramkowski E-Mail: tk@the-tk.com PGP: 6FCE87503AAF42AB3BF4 94FE40B037BA0A5B8680
participants (7)
-
"Jérôme M. Berger"
-
Anatol Pomozov
-
Daniel Micay
-
David Rosenstrauch
-
Marcel Kleinfeller
-
Patrick Burroughs
-
Tomasz Kramkowski