Hi Chuck, > Is this intended to run on Linux?
Yes. And thanks for the pointing out to SELinux. I'll add it to my checklist. --- The system is on very early stages now, so its parts are changing rapidly and I'm able to consider different approaches to its subsystems (including security). But I probably confused all of you with the words 'package manager'. It's the package manager only in the narrow sense. It's not trying to be another apt, yum etc. Sorry that I didn't provide much details, but the original topic is very precise and I think I'll return to it a bit later when the functionality of the system will be in more stable state. On 22 August 2016 at 20:17, Chuck Atkins <chuck.atk...@kitware.com> wrote: > Hi Egor, > Is this intended to run on Linux? If so, I think you're FAR better off > leveraging an existing security framework like SELinux, since it's actually > designed from the ground up to enforce these types of controls. You could > define a label that you place on the executables run by the package manager > and then enforce whatever restrictions and controls you feel are > appropriate. This will let you do things like block network access got the > specific CMake executable used by the package system. It allows the CMake > scripts to leverage all the available language and command features but > deny, ant a system level, actions you deem unsafe or harmful. > > ---------- > Chuck Atkins > Staff R&D Engineer, Scientific Computing > Kitware, Inc. > > > On Sun, Aug 21, 2016 at 2:02 PM, Egor Pugin <egor.pu...@gmail.com> wrote: >> >> > What is the attack you want to stop? What are bad scripts and commands >> > in this context? >> >> I wrote them in the first message. For example, >> - any cmake commands that use COMMAND keyword (execute_process(COMMAND >> ...), add_custom_{command|target}(...) etc. This will deny any user >> scripts, programs (wget, curl, rm, ...). >> - download commands (CMake's builtin curl) - they can fill the drives >> with trash. >> >> > CMake runs lots of commands all the time. Most can be changed by a user, >> > many are changed by the generator based on environment and whatnot. Any of >> > these may be bad commands -- based on configuration. >> >> Yes, and it should deny only stuff above in small CMakeLists.txt part >> that will be protected with some other commands or policies. >> >> > But if CMake gets a secure mode for your generator and if that is merged >> > upstream, then I need to know about that when reading or writing >> > CMakeLists.txt. >> >> For the moment I'm just asking about possibility of implementation of >> these features. Any decision will go from CMake guys, not from me. So, >> you shouldn't ask me about it. :) >> >> > Generated code is safe only as long as you very tightly control the >> > environment CMake runs in. >> >> I don't care what is around, what is in user env. This is his >> responsibility. I'm just worrying for my parts of CMake stuff. >> >> On 21 August 2016 at 20:43, Tobias Hunger <tobias.hun...@gmail.com> wrote: >> > Hi Egor, >> > >> > Am 21.08.2016 12:34 schrieb "Egor Pugin" <egor.pu...@gmail.com>: >> >> >> >> > What are the attack scenarios you want to defend against? What should >> >> > not be possible in your system that currently is in CMake? >> >> >> >> At least downloading or executing bad scripts and commands. >> > >> > What is the attack you want to stop? What are bad scripts and commands >> > in >> > this context? >> > >> > CMake runs lots of commands all the time. Most can be changed by a user, >> > many are changed by the generator based on environment and whatnot. Any >> > of >> > these may be bad commands -- based on configuration. >> > >> > Downloading can be done using internal commands or by running e.g. wget >> > or >> > curl, both of which are pretty widely available on developer machines. >> > >> >> > That forces me to keep more state in my head when reading >> >> > CMakeLists.txt >> >> > files. >> >> >> >> CMake files are generated in my system. That's what I mean when I said >> >> 'based on CMake'. >> > >> > Sure. But if CMake gets a secure mode for your generator and if that is >> > merged upstream, then I need to know about that when reading or writing >> > CMakeLists.txt. >> > >> >> It's like compiler compiler like yacc, bison, lex, flex. They are >> >> producing output not for human readers, but for computer parsers. >> >> And that's why generated code is safe and insertions from users are >> >> not. >> > >> > Generated code is safe only as long as you very tightly control the >> > environment CMake runs in. >> > >> >> Also in the most cases there's no any insertions at all, so it's rare >> >> case. >> > >> > I'm sure you know what you are doing:) >> > >> > Best 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 > > -- 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