Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Monday 02/02 at 12:16 -0800, Andy Lutomirski wrote: On Fri, Jan 30, 2015 at 5:58 PM, Calvin Owens calvinow...@fb.com wrote: On Thursday 01/29 at 17:30 -0800, Kees Cook wrote: On Tue, Jan 27, 2015 at 8:38 PM, Calvin Owens calvinow...@fb.com wrote: On Monday 01/26 at 15:43 -0800, Andrew Morton wrote: On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? The biggest difference is that if you do something like this: fd = open(/stuff, O_BLAH); map = mmap(NULL, 4096, PROT_BLAH, MAP_SHARED, fd, 0); close(fd); unlink(/stuff); ...then map_files/ gives you a way to get a file descriptor for /stuff, which you couldn't do with /proc/pid/maps. It's also something of a win if you just want to see what is mapped at a specific address, since you can just readlink() the symlink for the address range you care about and it will go grab the appropriate VMA and give you the answer. /proc/pid/maps requires walking the VMA tree, which is quite expensive for processes with many thousands of threads, even without the O(N^2) issue. (You have to know what address range you want though, since readdir() on map_files/ obviously has to walk the VMA tree just like /proc/N/maps.) This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Yes, the only difference is that you can follow the link as per above. I'll resend with a new message explaining that and the deletion thing. There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? While I was messing with it I used it a good bit and didn't see any issues, although I didn't actively try to fuzz it or anything. I'd be happy to write something to test hammering it in weird ways if you like. I'm also happy to write testcases for namespaces. So far as security issues, as others have pointed out you can't follow the links unless you can ptrace the process in question, which seems like a pretty solid guarantee. As Cyrill pointed out in the discussion about the documentation, that's the same protection as /proc/N/fd/*, and those links function in the same way. My concern here is that fd/*
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Monday 02/02 at 09:01 -0500, Austin S Hemmelgarn wrote: On 2015-01-30 20:58, Calvin Owens wrote: On Thursday 01/29 at 17:30 -0800, Kees Cook wrote: On Tue, Jan 27, 2015 at 8:38 PM, Calvin Owens calvinow...@fb.com wrote: On Monday 01/26 at 15:43 -0800, Andrew Morton wrote: On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? The biggest difference is that if you do something like this: fd = open(/stuff, O_BLAH); map = mmap(NULL, 4096, PROT_BLAH, MAP_SHARED, fd, 0); close(fd); unlink(/stuff); ...then map_files/ gives you a way to get a file descriptor for /stuff, which you couldn't do with /proc/pid/maps. It's also something of a win if you just want to see what is mapped at a specific address, since you can just readlink() the symlink for the address range you care about and it will go grab the appropriate VMA and give you the answer. /proc/pid/maps requires walking the VMA tree, which is quite expensive for processes with many thousands of threads, even without the O(N^2) issue. (You have to know what address range you want though, since readdir() on map_files/ obviously has to walk the VMA tree just like /proc/N/maps.) This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Yes, the only difference is that you can follow the link as per above. I'll resend with a new message explaining that and the deletion thing. There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? While I was messing with it I used it a good bit and didn't see any issues, although I didn't actively try to fuzz it or anything. I'd be happy to write something to test hammering it in weird ways if you like. I'm also happy to write testcases for namespaces. So far as security issues, as others have pointed out you can't follow the links unless you can ptrace the process in question, which seems like a pretty solid guarantee. As Cyrill pointed out in the discussion about the documentation, that's the same protection as /proc/N/fd/*, and those links function in the same way. My concern here is that fd/* are connected as streams, and while that has a certain level of badness as an external-to-the-process attacker, PTRACE_MODE_READ is much weaker than PTRACE_MODE_ATTACH (which is required for access to /proc/N/mem). Since these fds are the things mapped into memory on a process, writing to
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Fri, Jan 30, 2015 at 5:58 PM, Calvin Owens calvinow...@fb.com wrote: On Thursday 01/29 at 17:30 -0800, Kees Cook wrote: On Tue, Jan 27, 2015 at 8:38 PM, Calvin Owens calvinow...@fb.com wrote: On Monday 01/26 at 15:43 -0800, Andrew Morton wrote: On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? The biggest difference is that if you do something like this: fd = open(/stuff, O_BLAH); map = mmap(NULL, 4096, PROT_BLAH, MAP_SHARED, fd, 0); close(fd); unlink(/stuff); ...then map_files/ gives you a way to get a file descriptor for /stuff, which you couldn't do with /proc/pid/maps. It's also something of a win if you just want to see what is mapped at a specific address, since you can just readlink() the symlink for the address range you care about and it will go grab the appropriate VMA and give you the answer. /proc/pid/maps requires walking the VMA tree, which is quite expensive for processes with many thousands of threads, even without the O(N^2) issue. (You have to know what address range you want though, since readdir() on map_files/ obviously has to walk the VMA tree just like /proc/N/maps.) This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Yes, the only difference is that you can follow the link as per above. I'll resend with a new message explaining that and the deletion thing. There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? While I was messing with it I used it a good bit and didn't see any issues, although I didn't actively try to fuzz it or anything. I'd be happy to write something to test hammering it in weird ways if you like. I'm also happy to write testcases for namespaces. So far as security issues, as others have pointed out you can't follow the links unless you can ptrace the process in question, which seems like a pretty solid guarantee. As Cyrill pointed out in the discussion about the documentation, that's the same protection as /proc/N/fd/*, and those links function in the same way. My concern here is that fd/* are connected as streams, and while that has a certain level of badness as an external-to-the-process attacker, PTRACE_MODE_READ is much weaker than PTRACE_MODE_ATTACH (which is required for access to
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On 2015-01-30 20:58, Calvin Owens wrote: On Thursday 01/29 at 17:30 -0800, Kees Cook wrote: On Tue, Jan 27, 2015 at 8:38 PM, Calvin Owens calvinow...@fb.com wrote: On Monday 01/26 at 15:43 -0800, Andrew Morton wrote: On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? The biggest difference is that if you do something like this: fd = open(/stuff, O_BLAH); map = mmap(NULL, 4096, PROT_BLAH, MAP_SHARED, fd, 0); close(fd); unlink(/stuff); ...then map_files/ gives you a way to get a file descriptor for /stuff, which you couldn't do with /proc/pid/maps. It's also something of a win if you just want to see what is mapped at a specific address, since you can just readlink() the symlink for the address range you care about and it will go grab the appropriate VMA and give you the answer. /proc/pid/maps requires walking the VMA tree, which is quite expensive for processes with many thousands of threads, even without the O(N^2) issue. (You have to know what address range you want though, since readdir() on map_files/ obviously has to walk the VMA tree just like /proc/N/maps.) This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Yes, the only difference is that you can follow the link as per above. I'll resend with a new message explaining that and the deletion thing. There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? While I was messing with it I used it a good bit and didn't see any issues, although I didn't actively try to fuzz it or anything. I'd be happy to write something to test hammering it in weird ways if you like. I'm also happy to write testcases for namespaces. So far as security issues, as others have pointed out you can't follow the links unless you can ptrace the process in question, which seems like a pretty solid guarantee. As Cyrill pointed out in the discussion about the documentation, that's the same protection as /proc/N/fd/*, and those links function in the same way. My concern here is that fd/* are connected as streams, and while that has a certain level of badness as an external-to-the-process attacker, PTRACE_MODE_READ is much weaker than PTRACE_MODE_ATTACH (which is required for access to /proc/N/mem). Since these fds are the things mapped into memory on a process, writing to them is a subset of access to /proc/N/mem, and I don't feel that PTRACE_MODE_READ is sufficient. If you haven't done close() on a mmapped file, doesn't
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Thursday 01/29 at 17:30 -0800, Kees Cook wrote: On Tue, Jan 27, 2015 at 8:38 PM, Calvin Owens calvinow...@fb.com wrote: On Monday 01/26 at 15:43 -0800, Andrew Morton wrote: On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? The biggest difference is that if you do something like this: fd = open(/stuff, O_BLAH); map = mmap(NULL, 4096, PROT_BLAH, MAP_SHARED, fd, 0); close(fd); unlink(/stuff); ...then map_files/ gives you a way to get a file descriptor for /stuff, which you couldn't do with /proc/pid/maps. It's also something of a win if you just want to see what is mapped at a specific address, since you can just readlink() the symlink for the address range you care about and it will go grab the appropriate VMA and give you the answer. /proc/pid/maps requires walking the VMA tree, which is quite expensive for processes with many thousands of threads, even without the O(N^2) issue. (You have to know what address range you want though, since readdir() on map_files/ obviously has to walk the VMA tree just like /proc/N/maps.) This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Yes, the only difference is that you can follow the link as per above. I'll resend with a new message explaining that and the deletion thing. There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? While I was messing with it I used it a good bit and didn't see any issues, although I didn't actively try to fuzz it or anything. I'd be happy to write something to test hammering it in weird ways if you like. I'm also happy to write testcases for namespaces. So far as security issues, as others have pointed out you can't follow the links unless you can ptrace the process in question, which seems like a pretty solid guarantee. As Cyrill pointed out in the discussion about the documentation, that's the same protection as /proc/N/fd/*, and those links function in the same way. My concern here is that fd/* are connected as streams, and while that has a certain level of badness as an external-to-the-process attacker, PTRACE_MODE_READ is much weaker than PTRACE_MODE_ATTACH (which is required for access to /proc/N/mem). Since these fds are the things mapped into memory on a process,
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Tue, Jan 27, 2015 at 8:38 PM, Calvin Owens calvinow...@fb.com wrote: On Monday 01/26 at 15:43 -0800, Andrew Morton wrote: On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? The biggest difference is that if you do something like this: fd = open(/stuff, O_BLAH); map = mmap(NULL, 4096, PROT_BLAH, MAP_SHARED, fd, 0); close(fd); unlink(/stuff); ...then map_files/ gives you a way to get a file descriptor for /stuff, which you couldn't do with /proc/pid/maps. It's also something of a win if you just want to see what is mapped at a specific address, since you can just readlink() the symlink for the address range you care about and it will go grab the appropriate VMA and give you the answer. /proc/pid/maps requires walking the VMA tree, which is quite expensive for processes with many thousands of threads, even without the O(N^2) issue. (You have to know what address range you want though, since readdir() on map_files/ obviously has to walk the VMA tree just like /proc/N/maps.) This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Yes, the only difference is that you can follow the link as per above. I'll resend with a new message explaining that and the deletion thing. There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? While I was messing with it I used it a good bit and didn't see any issues, although I didn't actively try to fuzz it or anything. I'd be happy to write something to test hammering it in weird ways if you like. I'm also happy to write testcases for namespaces. So far as security issues, as others have pointed out you can't follow the links unless you can ptrace the process in question, which seems like a pretty solid guarantee. As Cyrill pointed out in the discussion about the documentation, that's the same protection as /proc/N/fd/*, and those links function in the same way. My concern here is that fd/* are connected as streams, and while that has a certain level of badness as an external-to-the-process attacker, PTRACE_MODE_READ is much weaker than PTRACE_MODE_ATTACH (which is required for access to /proc/N/mem). Since these fds are the things mapped into memory on a process, writing to them is a subset of access to /proc/N/mem, and I don't feel that PTRACE_MODE_READ is sufficient. -Kees -- Kees Cook Chrome OS Security -- To
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Mon, Jan 26, 2015 at 11:37 PM, Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 04:15:26PM -0800, Kees Cook wrote: akpm3:/usr/src/25 grep -r map_files Documentation If akpm's comments weren't clear: this needs to be fixed. Everything in /proc should appear in Documentation. I'll do that. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so How is mmap offset represented in this output? We're printing vm_area_struct:[vm_start;vm_end] only. afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Both maps and map_files uses ptrace_may_access (via mm_acces) with PTRACE_MODE_READ, so I'm happy from a info leak perspective. Are mount namespaces handled in this output? Could you clarify this moment, i'm not sure i get it. I changed how I asked this question in my review of the documentation, but it looks like these symlinks aren't regular symlinks (that are up to the follower to have access to the file system path shown), but rather they bypass VFS. As a result, I'm wondering how things like mount namespaces might change this behavior: what is shown, the path from the perspective of the target, or from the viewer (which may be in separate mount namespaces). -Kees There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Tue, Jan 27, 2015 at 11:53:19AM -0800, Kees Cook wrote: Are mount namespaces handled in this output? Could you clarify this moment, i'm not sure i get it. I changed how I asked this question in my review of the documentation, but it looks like these symlinks aren't regular symlinks (that are up to the follower to have access to the file system path shown), but rather they bypass VFS. As a result, I'm wondering how things like mount namespaces might change this behavior: what is shown, the path from the perspective of the target, or from the viewer (which may be in separate mount namespaces). I must admit I personally didn't investigating how mount namespaces might itercat with map-files. Pavel, could you share the thoughts? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
Are mount namespaces handled in this output? Could you clarify this moment, i'm not sure i get it. I changed how I asked this question in my review of the documentation, but it looks like these symlinks aren't regular symlinks (that are up to the follower to have access to the file system path shown), but rather they bypass VFS. As a result, I'm wondering how things like mount namespaces might change this behavior: what is shown, the path from the perspective of the target, or from the viewer (which may be in separate mount namespaces). These work just like the /proc/$pid/fd/$n links do. When you readlink on it the d_path() is called which walks up the dentry/vfsmnt tree until it reaches either current root or the global one. For another mount namespace case it produces the path relative to this namespace's root. Thanks, Pavel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Monday 01/26 at 15:43 -0800, Andrew Morton wrote: On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? The biggest difference is that if you do something like this: fd = open(/stuff, O_BLAH); map = mmap(NULL, 4096, PROT_BLAH, MAP_SHARED, fd, 0); close(fd); unlink(/stuff); ...then map_files/ gives you a way to get a file descriptor for /stuff, which you couldn't do with /proc/pid/maps. It's also something of a win if you just want to see what is mapped at a specific address, since you can just readlink() the symlink for the address range you care about and it will go grab the appropriate VMA and give you the answer. /proc/pid/maps requires walking the VMA tree, which is quite expensive for processes with many thousands of threads, even without the O(N^2) issue. (You have to know what address range you want though, since readdir() on map_files/ obviously has to walk the VMA tree just like /proc/N/maps.) This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Yes, the only difference is that you can follow the link as per above. I'll resend with a new message explaining that and the deletion thing. There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? While I was messing with it I used it a good bit and didn't see any issues, although I didn't actively try to fuzz it or anything. I'd be happy to write something to test hammering it in weird ways if you like. I'm also happy to write testcases for namespaces. So far as security issues, as others have pointed out you can't follow the links unless you can ptrace the process in question, which seems like a pretty solid guarantee. As Cyrill pointed out in the discussion about the documentation, that's the same protection as /proc/N/fd/*, and those links function in the same way. Thanks, Calvin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote:
Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and
is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface
is very useful for enumerating the files mapped into a process when
the more verbose information in /proc/pid/maps is not needed.
This patch moves the folder out from behind CHECKPOINT_RESTORE, and
removes the CAP_SYS_ADMIN restrictions. Following the links requires
the ability to ptrace the process in question, so this doesn't allow
an attacker to do anything they couldn't already do before.
Signed-off-by: Calvin Owens calvinow...@fb.com
Cc +linux-api@
---
Changes in v2:Removed the follow_link() stub that returned -EPERM if
the caller didn't have CAP_SYS_ADMIN, since the caller
in my chroot() scenario gets -EACCES anyway.
fs/proc/base.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 3f3d7ae..67b15ac 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1632,8 +1632,6 @@ end_instantiate:
return dir_emit(ctx, name, len, 1, DT_UNKNOWN);
}
-#ifdef CONFIG_CHECKPOINT_RESTORE
-
/*
* dname_to_vma_addr - maps a dentry name into two unsigned longs
* which represent vma start and end addresses.
@@ -1660,11 +1658,6 @@ static int map_files_d_revalidate(struct dentry
*dentry, unsigned int flags)
if (flags LOOKUP_RCU)
return -ECHILD;
- if (!capable(CAP_SYS_ADMIN)) {
- status = -EPERM;
- goto out_notask;
- }
-
inode = dentry-d_inode;
task = get_proc_task(inode);
if (!task)
@@ -1792,10 +1785,6 @@ static struct dentry *proc_map_files_lookup(struct
inode *dir,
int result;
struct mm_struct *mm;
- result = -EPERM;
- if (!capable(CAP_SYS_ADMIN))
- goto out;
-
result = -ENOENT;
task = get_proc_task(dir);
if (!task)
@@ -1849,10 +1838,6 @@ proc_map_files_readdir(struct file *file, struct
dir_context *ctx)
struct map_files_info *p;
int ret;
- ret = -EPERM;
- if (!capable(CAP_SYS_ADMIN))
- goto out;
-
ret = -ENOENT;
task = get_proc_task(file_inode(file));
if (!task)
@@ -2040,7 +2025,6 @@ static const struct file_operations
proc_timers_operations = {
.llseek = seq_lseek,
.release= seq_release_private,
};
-#endif /* CONFIG_CHECKPOINT_RESTORE */
static int proc_pident_instantiate(struct inode *dir,
struct dentry *dentry, struct task_struct *task, const void *ptr)
@@ -2537,9 +2521,7 @@ static const struct inode_operations
proc_task_inode_operations;
static const struct pid_entry tgid_base_stuff[] = {
DIR(task, S_IRUGO|S_IXUGO, proc_task_inode_operations,
proc_task_operations),
DIR(fd, S_IRUSR|S_IXUSR, proc_fd_inode_operations,
proc_fd_operations),
-#ifdef CONFIG_CHECKPOINT_RESTORE
DIR(map_files, S_IRUSR|S_IXUSR, proc_map_files_inode_operations,
proc_map_files_operations),
-#endif
DIR(fdinfo, S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations,
proc_fdinfo_operations),
DIR(ns, S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations,
proc_ns_dir_operations),
#ifdef CONFIG_NET
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Tue, 27 Jan 2015 09:46:47 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? I didn't find any bugs in map-files (and we use it for long time already) so I think it is safe. You've been using map_files the way it was supposed to be used so no, any bugs won't show up. What happens if you don your evil black hat and use map_files in ways that weren't anticipated? Attack it? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Mon, Jan 26, 2015 at 10:50:23PM -0800, Andrew Morton wrote: On Tue, 27 Jan 2015 09:46:47 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? I didn't find any bugs in map-files (and we use it for long time already) so I think it is safe. You've been using map_files the way it was supposed to be used so no, any bugs won't show up. What happens if you don your evil black hat and use map_files in ways that weren't anticipated? Attack it? Hard to say, Andrew. If I found a way to exploit this feature for bad purpose for sure I would patch it out. At the moment I don't see any. Touching another process memory via file descriptor allows one to modify its contents but you have to be granted ptrace-may-access which i consider as enough for security. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Mon, Jan 26, 2015 at 03:43:46PM -0800, Andrew Morton wrote: Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. yup, I managed to forget CC him. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. Sigh. Imagine, for some reason I though we've the docs for that entry, probably i though that way because of many fdinfo snippets i've putted into /proc docs. my bad, sorry. I'll try to prepare docs today. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? I didn't find any bugs in map-files (and we use it for long time already) so I think it is safe. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Mon, Jan 26, 2015 at 3:43 PM, Andrew Morton a...@linux-foundation.org wrote: On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation If akpm's comments weren't clear: this needs to be fixed. Everything in /proc should appear in Documentation. akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so How is mmap offset represented in this output? afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Both maps and map_files uses ptrace_may_access (via mm_acces) with PTRACE_MODE_READ, so I'm happy from a info leak perspective. Are mount namespaces handled in this output? There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Mon, Jan 26, 2015 at 04:15:26PM -0800, Kees Cook wrote: akpm3:/usr/src/25 grep -r map_files Documentation If akpm's comments weren't clear: this needs to be fixed. Everything in /proc should appear in Documentation. I'll do that. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so How is mmap offset represented in this output? We're printing vm_area_struct:[vm_start;vm_end] only. afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). Both maps and map_files uses ptrace_may_access (via mm_acces) with PTRACE_MODE_READ, so I'm happy from a info leak perspective. Are mount namespaces handled in this output? Could you clarify this moment, i'm not sure i get it. There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? (Please add to changelog). There's one other problem here: we're assuming that the map_files implementation doesn't have bugs. If it does have bugs then relaxing permissions like this will create new vulnerabilities. And the map_files implementation is surprisingly complex. Is it bug-free? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Mon, Jan 26, 2015 at 03:43:46PM -0800, Andrew Morton wrote: On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov gorcu...@gmail.com wrote: On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This is the main (actually only) justification for the patch, and it it far too thin. What does not needed mean. Why can't people just use /proc/pid/maps? This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. hm, who's that. Kees comes to mind. And reviewers' task would be a heck of a lot easier if they knew what /proc/pid/map_files actually does. This: akpm3:/usr/src/25 grep -r map_files Documentation akpm3:/usr/src/25 does not help. The 640708a2cff7f81 changelog says: : This one behaves similarly to the /proc/pid/fd/ one - it contains : symlinks one for each mapping with file, the name of a symlink is : vma-vm_start-vma-vm_end, the target is the file. Opening a symlink : results in a file that point exactly to the same inode as them vma's one. : : For example the ls -l of some arbitrary /proc/pid/map_files/ : : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 - /lib64/libc-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 - /lib64/libselinux.so.1 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 - /lib64/libacl.so.1.1.0 : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 - /lib64/librt-2.5.so : | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 - /lib64/ld-2.5.so afacit this info is also available in /proc/pid/maps, so things shouldn't get worse if the /proc/pid/map_files permissions are at least as restrictive as the /proc/pid/maps permissions. Is that the case? Almost. IIUC, before we haven't had a way to retrieve a file descriptor from mapped file if it was closed and not accessible for direct re-open. Like in chroot case or unlink after close. I'm not sure what security implications this move has, if any. I don't see anything obviously dangerous. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote: On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote: Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is very useful for enumerating the files mapped into a process when the more verbose information in /proc/pid/maps is not needed. This patch moves the folder out from behind CHECKPOINT_RESTORE, and removes the CAP_SYS_ADMIN restrictions. Following the links requires the ability to ptrace the process in question, so this doesn't allow an attacker to do anything they couldn't already do before. Signed-off-by: Calvin Owens calvinow...@fb.com Cc +linux-api@ Looks good to me, thanks! Though I would really appreciate if someone from security camp take a look as well. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v2] procfs: Always expose /proc/pid/map_files/ and make it readable
Currently, /proc/pid/map_files/ is restricted to CAP_SYS_ADMIN, and
is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface
is very useful for enumerating the files mapped into a process when
the more verbose information in /proc/pid/maps is not needed.
This patch moves the folder out from behind CHECKPOINT_RESTORE, and
removes the CAP_SYS_ADMIN restrictions. Following the links requires
the ability to ptrace the process in question, so this doesn't allow
an attacker to do anything they couldn't already do before.
Signed-off-by: Calvin Owens calvinow...@fb.com
---
Changes in v2: Removed the follow_link() stub that returned -EPERM if
the caller didn't have CAP_SYS_ADMIN, since the caller
in my chroot() scenario gets -EACCES anyway.
fs/proc/base.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 3f3d7ae..67b15ac 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1632,8 +1632,6 @@ end_instantiate:
return dir_emit(ctx, name, len, 1, DT_UNKNOWN);
}
-#ifdef CONFIG_CHECKPOINT_RESTORE
-
/*
* dname_to_vma_addr - maps a dentry name into two unsigned longs
* which represent vma start and end addresses.
@@ -1660,11 +1658,6 @@ static int map_files_d_revalidate(struct dentry *dentry,
unsigned int flags)
if (flags LOOKUP_RCU)
return -ECHILD;
- if (!capable(CAP_SYS_ADMIN)) {
- status = -EPERM;
- goto out_notask;
- }
-
inode = dentry-d_inode;
task = get_proc_task(inode);
if (!task)
@@ -1792,10 +1785,6 @@ static struct dentry *proc_map_files_lookup(struct inode
*dir,
int result;
struct mm_struct *mm;
- result = -EPERM;
- if (!capable(CAP_SYS_ADMIN))
- goto out;
-
result = -ENOENT;
task = get_proc_task(dir);
if (!task)
@@ -1849,10 +1838,6 @@ proc_map_files_readdir(struct file *file, struct
dir_context *ctx)
struct map_files_info *p;
int ret;
- ret = -EPERM;
- if (!capable(CAP_SYS_ADMIN))
- goto out;
-
ret = -ENOENT;
task = get_proc_task(file_inode(file));
if (!task)
@@ -2040,7 +2025,6 @@ static const struct file_operations
proc_timers_operations = {
.llseek = seq_lseek,
.release= seq_release_private,
};
-#endif /* CONFIG_CHECKPOINT_RESTORE */
static int proc_pident_instantiate(struct inode *dir,
struct dentry *dentry, struct task_struct *task, const void *ptr)
@@ -2537,9 +2521,7 @@ static const struct inode_operations
proc_task_inode_operations;
static const struct pid_entry tgid_base_stuff[] = {
DIR(task, S_IRUGO|S_IXUGO, proc_task_inode_operations,
proc_task_operations),
DIR(fd, S_IRUSR|S_IXUSR, proc_fd_inode_operations,
proc_fd_operations),
-#ifdef CONFIG_CHECKPOINT_RESTORE
DIR(map_files, S_IRUSR|S_IXUSR, proc_map_files_inode_operations,
proc_map_files_operations),
-#endif
DIR(fdinfo, S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations,
proc_fdinfo_operations),
DIR(ns, S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations,
proc_ns_dir_operations),
#ifdef CONFIG_NET
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
