[cmake-developers] Security in CMake

Egor Pugin egor.pugin at gmail.com
Sun Aug 21 06:34:41 EDT 2016


> 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.

> 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'.
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.
Also in the most cases there's no any insertions at all, so it's rare case.

On 21 August 2016 at 11:24, Tobias Hunger <tobias.hunger at gmail.com> wrote:
> Hi Egor,
>
> Am 20.08.2016 23:42 schrieb "Egor Pugin" <egor.pugin at gmail.com>:
>> 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.
>
> Retrofitting security into a product that was designed without any
> consideration for security from the start is going to be hard.
>
> I do not know what you want to do, so I am not going to claim it is
> impossible:-)
>
>> 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.
>
> What are the attack scenarios you want to defend against? What should not be
> possible in your system that currently is in CMake? How do these steps help
> in securing against those attacks?
>
> As a user of CMake I am very much opposed to disabling functionality based
> on the context: That forces me to keep more state in my head when reading
> CMakeLists.txt files. CMake does way too much in a way to obscure syntax
> already!
>
> Best regards,
> Tobias
>
>> On 21 August 2016 at 00:25, Tobias Hunger <tobias.hunger at gmail.com> wrote:
>> > Hi Egor,
>> >
>> > Am 20.08.2016 13:48 schrieb "Egor Pugin" <egor.pugin at gmail.com>:
>> >>
>> >> 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



-- 
Egor Pugin


More information about the cmake-developers mailing list