Layer7 Privileged Access Management

Expand all | Collapse all

Is CA PIM Agent blocking kernel syscalls?

  • 1.  Is CA PIM Agent blocking kernel syscalls?

    Posted 07-18-2018 11:13 AM

    Hi gurus,


    last day I have a issue with a my monitoring solution. First all I didn't setup any rule on the Agent, it is only do nothing..


    I checked with top which app is consuming CPU ..


    top util output


    So I checked with secons kernel syscalls


    [root@it-lin-fxs-web-01 bin]# ./secons -sc

    CA ControlMinder secons v12.81.0.2878 - Console utility

    Copyright (c) 2013 CA. All rights reserved.

    Active system calls:


    syscall #2 - PID: 2326

    syscall #43 - PID: 9837 9835 9834 9831 4037 2418 592 9836 2415 9830 593 591 9833 9832 2409 2414 3793 3798 2198 3798


    I checked with ps tool which program has PID 2326


    [root@it-lin-fxs-web-01 bin]# ps --ps -fea | grep 2326

    newrelic  2326  2324 12 Jul12 ?        17:25:02 /usr/sbin/nrsysmond -c /etc/newrelic/nrsysmond.cfg -p /var/run/newrelic/


    So, Is CA PIM Blocking any monitoring tool kernel syscall?




  • 2.  Re: Is CA PIM Agent blocking kernel syscalls?

    Posted 07-19-2018 01:44 AM

    Hello Sergio,


    You may check the seaudit for clues if there are any denials preventing operation of the program.


    You can also enable seosd.trace at runtime by issuing in a root shell

    # secons -tc ; secons -t+

    and see in the file if you find any pattern or hints


    Do not forget to disable the tracing again

    # secons -t-




  • 3.  Re: Is CA PIM Agent blocking kernel syscalls?

    Posted 07-19-2018 12:25 PM

    Thanks Andreas, but the auditfile register nothing about and I seosd.trace is on.





  • 4.  Re: Is CA PIM Agent blocking kernel syscalls?

    Posted 07-19-2018 12:44 PM

    Hi Seralar,


    Did the system crash or was there a product core?  If the system is hanging, you may have also experienced a crash dump or a core dump from either the native OS or the actual enterprise application.  You can typically find these in /var/crash, or /opt/CA/AccessControl, under naming schemes such as, core.*, vmcore, vmlinux, and*.


    Perhaps you need to incorporate a SPECIALPGM to allow a bypass.  This effectively allows setting access permissions according to what is being done rather than who is doing it:

    er SPECIALPGM (/path/to/new_relic_binary) owner(nobody) pgmtype(fullbypass)


    This rule fully bypasses all authorization and database checks. CA PIM ignores a process that has this property, and no record of any process events appears in audit, trace, or debug logs.


    I hope this helps you.