[cmake-developers] Security in CMake

Egor Pugin egor.pugin at gmail.com
Mon Aug 22 13:52:24 EDT 2016


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.atkins at 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.pugin at 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.hunger at gmail.com> wrote:
>> > Hi Egor,
>> >
>> > Am 21.08.2016 12:34 schrieb "Egor Pugin" <egor.pugin at 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


More information about the cmake-developers mailing list