WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: dirty COW  (Read 2800 times)

Offline nagtiny

  • Newbie
  • *
  • Posts: 7
dirty COW
« on: October 24, 2016, 05:19:34 AM »
hi,
i post this one here because i use the 64bit port of tinycore, even if the problem exists also for the 32bit kernel.
are there any plans to update the current kernel to mitigate the 'dirty cow' bug?
and if so, what will be the time scale? i like the the tinycore approach very much, as in my opinion a nearly stateless readonly system with such a small footprint is an ideal base for all sorts of (security) appliances, so this fix would be very important for me.
i could build the kernel myself, but i would prefer to use an unmodified system for supporting purpose.
thank you very much!
regards
roger

Online curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10941
Re: dirty COW
« Reply #1 on: October 24, 2016, 07:18:30 AM »
No plans. The next version is planned in a few months, and it would ship with a kernel new enough to not have that bug, if you can wait.

Generally we keep the same kernel in a version, unless there's severe functional bugs. This is both for the embedded focus, where no kernel changes helps keeping things stable (the support argument you also mention), as well as due to limited manpower.

Standard disclaimer: there's always bugs, including security bugs. Dirty cow is a local one, meaning attackers have a shell or physical access.
The only barriers that can stop you are the ones you create yourself.

Online curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10941
Re: dirty COW
« Reply #2 on: October 24, 2016, 07:39:36 AM »
Oh, addition to the standard disclaimer: if security is worth more than performance, you should run the grsecurity kernels.
The only barriers that can stop you are the ones you create yourself.

Offline nagtiny

  • Newbie
  • *
  • Posts: 7
Re: dirty COW
« Reply #3 on: October 26, 2016, 07:17:13 AM »
thank you very much for your answer.
using grsecurity would be a great way to improve security, i will test this and post my findings.

for the moment, i just patched the current 4.2.9 kernel and recompiled it - even if this flaw is a "local one", one never knows if there are other flaws which may give a shell to an attacker.

did i understand you correctly, the reason not patching the kernel with such severe security fixes is due to limited manpower?
how may I help with this?

Online curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10941
Re: dirty COW
« Reply #4 on: October 27, 2016, 02:34:41 AM »
Even with manpower, each patch may cause regressions, as well as incompatibilities with out-of-tree modules - which would then cause trouble for some users.
The only barriers that can stop you are the ones you create yourself.

Offline netnomad

  • Hero Member
  • *****
  • Posts: 1026
Re: dirty COW
« Reply #5 on: November 05, 2016, 06:10:56 AM »
hi nagtiny,

i really appreciate your approach and awareness in security.
if you want to offer this forum alternative kernels for dcore,
you will find in me an active partner for heavy testing :-)

thank you for your help and contributions to the community.