I recently tried to install a new ubuntu kernel (4.10.0-22). It failed, it seems due to Sophos.

I recently tried to install the latest kernel for ubuntu 17.04 - 4.10.0-22.  It kept failing saying an "operation was not permitted".  When I reported this on the ubuntu bug tracker it was suggested I turn off anti-virus and try again. 

I disabled the on-access scan and tried again, and installation worked.

I had no warnings or alerts from sophos.  I checked that the sophos warnings and emails were on and worked (I tested using the test virus file) and that all worked.

So, somehow sophos is preventing a file access.  I am on the latest version, including talpa.

The ubuntu report with full details is at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1696132 

Regards

  • Hello pastim,

    somehow sophos is preventing a file access
    looks like ... but actually I'm just replying to point this out to   by mentioning his name. Smile

    Christian

  • syslog should show why talpa blocked access to /usr/src/linux-headers-4.10.0-22-generic/include/config/dw/dmac/core.h.dpkg-new

     

    # grep talpa /var/log/syslog

     

    The only errors I could see in the bug were segfaults.

  • In reply to DouglasLeeder:

    I have 3 systems on ubuntu 17.04 running Sophos, and only one had this problem.   It is a fact that disabling on-access scanning circumvented the crash on the one system, but I've no idea why, nor why the other 2 systems had no problem.  I tried this kernel update many times and it failed every single time on the one system until I did this.

    All I can find in the syslog is this. Is there anything else I can supply that would help?  Note that the 'operation not permitted' error sometimes seemed to happen on different files when I tried installing again.


    Jun 6 14:32:14 ChrisP AptDaemon.Worker: INFO: Processing transaction /org/debian/apt/transaction/80fb41eb7891454a9a34704fc84e3ddf
    Jun 6 14:32:14 ChrisP org.debian.apt[904]: 14:32:14 AptDaemon.Worker [INFO]: Processing transaction /org/debian/apt/transaction/80fb41eb7891454a9a34704fc84e3ddf
    Jun 6 14:33:06 ChrisP NetworkManager[948]: <info> [1496755986.0826] manager: kernel firmware directory '/lib/firmware' changed
    Jun 6 14:33:17 ChrisP AptDaemon.Worker: CRITICAL: /tmp/apt-dpkg-install-qSYV0L/3-linux-image-extra-4.10.0-22-generic_4.10.0-22.24_amd64.deb: unable to open '/lib/modules/4.10.0-22-generic/kernel/drivers/isdn/hisax/sedlbauer_cs.ko.dpkg-new': Operation not permitted
    Jun 6 14:33:17 ChrisP org.debian.apt[904]: 14:33:17 AptDaemon.Worker [CRITICAL]: /tmp/apt-dpkg-install-qSYV0L/3-linux-image-extra-4.10.0-22-generic_4.10.0-22.24_amd64.deb: unable to open '/lib/modules/4.10.0-22-generic/kernel/drivers/isdn/hisax/sedlbauer_cs.ko.dpkg-new': Operation not permitted
    Jun 6 14:33:17 ChrisP kernel: [29149.386737] show_signal_msg: 33 callbacks suppressed
    Jun 6 14:33:17 ChrisP kernel: [29149.386740] aptd[13060]: segfault at 0 ip 00007fbb74c09cfb sp 00007ffe5b30b460 error 4 in libc-2.24.so[7fbb74b9b000+1bd000]
    Jun 6 14:33:36 ChrisP AptDaemon.Worker: INFO: Finished transaction /org/debian/apt/transaction/80fb41eb7891454a9a34704fc84e3ddf

  • In reply to pastim:

    Sorry, is on-access enabled with Talpa or fanotify?

     

    I can't see any Talpa messages in syslog, so I'm guessing it might be fanotify, in which case it might be much harder to diagnose why the machine is blocking those files.

     

    The diagnose output might help: https://community.sophos.com/kb/en-us/33556

  • In reply to DouglasLeeder:

    I just had a look again, and it turns out that that system was using fanotify, whereas my other 2 were using talpa.  I don't know why (maybe I didn't update talpa properly for the previous kernel updates), but it is now using talpa.

    This may at least explain why 2 systems updated the kernel OK and one wasn't (ie. a fanotify issue).

    Would you like me to submit the diagnose output?  I don't know if it will contain information from 5th/6th june or not.

  • In reply to pastim:

    I am unclear whether I can submit the diagnose output or not.  I am using the free unsupported version, so I don't think I have the credentials, ticket etc to do so.  I'll happily do it if there's a way and if it will be helpful to you.  I probably won't be able to test any fix since all is now working OK.

  • In reply to pastim:

    Yes, I agree, I'm not sure the logs will show any more information about why fanotify blocked access to the files while installing the update.

     

  • In reply to DouglasLeeder:

    If you want me to email the diagnose output to you or some other email address I will happily do so - let me know - it's about 5.4MB.  Otherwise I guess we'll have to leave it.  OK?

  • In reply to pastim:

    I think we'll have to leave it. Sorry about that.

  • In reply to DouglasLeeder:

    That's OK.  Just trying to help :)

    As a final note, the reason that system was using fanotify rather than talpa was that it didn't have the linux headers for the older kernel I was using to avoid a newer kernel that was crashing the system. So Talpa wasn't compiling, and I wasn't noticing any alerts or looking at any logs that would have told me.  I should check the logs more often!

  • In reply to pastim:

    So, it means you used the headers for the older kernel with the new one?

  • In reply to Ana James:

    No.  Talpa failed to compile, so it fell back onto fanotify.

  • Hello

    I had the same issue.

    Exemple

     

    root@debian:/# apt install linux-image-4.19.0-2-amd64-unsigned
    dpkg: erreur de traitement de l'archive /var/cache/apt/archives/linux-image-4.19.0-2-amd64-unsigned_4.19.16-1_amd64.deb (--unpack) :
    impossible d'ouvrir « /lib/modules/4.19.0-2-amd64/kernel/drivers/net/ethernet/chelsio/libcxgb/libcxgb.ko.dpkg-new »: Opération non permise

     

    Can't open the file, is it because the dpkg-new extension?

    After 

     

    systemctl stop sav-protect.service

     

    Everything is ok

  • In reply to grand toubab:

    Running systemctl like that will disable SAV entirely, so it won't be protecting your system.

     

    The previous person was using fanotify, so you could check if you are using fanotify or talpa, to see if you have the same issue.

     

    Unfortunately fanotify gives less information about why it is blocking access, so unless the SAV log shows why it's blocking access.

  • In reply to DouglasLeeder:

    This problem went away for me quite a while ago.  I've been using talpa for well over a year now with no further problems.  I'm on a much more recent kernel, and get talpa via 

    gist.github.com/.../7892031