> 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 <[email protected]> wrote:
> Hi Egor,
>
> Am 21.08.2016 12:34 schrieb "Egor Pugin" <[email protected]>:
>>
>> > 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
