Hello Community, i had to check the DKIM keys that in created with ISPConfig3.1 in the filesystem: Code: root@server:~# ls -l /var/lib/amavis/dkim/ total 32 -rw-r--r-- 1 root root 902 Okt 4 14:33 domain1.de.private -rw-r--r-- 1 root root 272 Okt 4 14:33 domain1.de.public -rw-r--r-- 1 root root 902 Okt 6 20:57 domain2.de.private -rw-r--r-- 1 root root 272 Okt 6 20:57 domain2.de.public -rw-r--r-- 1 root root 902 Okt 4 14:35 domain3.de.private -rw-r--r-- 1 root root 272 Okt 4 14:35 domain3.de.public -rw-r--r-- 1 root root 902 Okt 4 14:28 domain4.de.private -rw-r--r-- 1 root root 272 Okt 4 14:28 domain4.de.public root@server:~# ~ Shouldn't the private DKIM keys better be 0600 (-rw-------) and user amavis? What do i ve to do that newly uploaded(?) or generated Keys have the proper file permissions? thx p.s. I know how to use chmod , but it is not an automated sollution
well, to change the permissions of the directory seems a sollution in the first sight. but as an attacker i am still able to set an inode (e.g. a hardlink) to the content of the private keys and as matter of the read permissions for all i am still able to read the content. so it is not really a work around.
How would you? You'd have to be root to do that as you don't have access to any contents of the directory as normal user.
it doesnt metter. to set an hardlink u needn't to ve access to a directory the file permissions are important. it is a filesystem matter. directorys are just an overlaying structure. Ext file system has Inodes where it stores its data (like a pointer in C). so the directory is just pointing to that inodes so if i know the path i easyly can set an hardlink. but even so. i think it is smart to narrow down the vector of attack. so to setup the proper permissions for a cryptographic key is crusual. thx
I don't question that the file permissions might be better set differently, but I doubt that you can set a hardlink. Code: cd /home mkdir test chown amavis:amavis test chmod 750 test echo "hello" > /home/test/test.txt chown root:root /home/test/test.txt chmod 644 /home/test/test.txt su username ln /home/test/test.txt /home/username/myfile.txt -> permission denied.
mhhh, i see. somehow i remember from my unix courses that there was a problem with inodes and links. how about a symlink. that should be possible. also it depends on the the shell and ln binary that u are using. and an possible attacker of course is not coming into the front door. the attacker makes it own binary and might use a code injection for deployment.
You can set a symlink of course, but accessing this would result in permission denied, then (as it uses the permissions of the real file/folder target). In this case you have real problems that you won't solve by changing any file permissions
of course it would be painfull but well, is it wrong to secure the things up a bit more? is it wrong to care for containment in the matter of a data breach? specially when there are billion lines of code from thousands of libraries linked to hunderts of binary runing a dozen of services?
Well. here is the issue i was refering for. but de directory is not world writable so it should not be an issue: I just somehow felt alarmed about it....
