Project Home
Project Home		 Trackers
Trackers		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Community/Discussion/General/'dumper' running on non-root does not work without secpogenerate/List of Posts
Forum Topic - 'dumper' running on non-root does not work without secpogenerate: (8 Items)
   
Update
Gauresh Badve(deleted)
06/27/2019 9:59 AM
post119767
'dumper' running on non-root does not work without secpogenerate   
Let me explain my scenario:
Version : QNX 7.0.0

I am using secpolgenerate utility to generate security policy for the dumper. The secpolgenerate observes all the 
behavior of the dumper and creates a policy file at /dev/secpolgenerate/policy.

The command I used for secpolgenerate:
'secpolgenerate -u -t 100'

I start the dumper using command:
on -T dumper_t /proc/boot/dumper -U 112 ( Here 112 is the user id on which I want the dumper to run and dumper_t is the 
type defined for dumper in the security policy file )

The "pidin ar" command shows the dumper running with user id - 112 and also the policy file generated in location /dev/
secpolgenerate/policy shows all the abilities the type dumper_t require to run the dumper.

The same generated policy( at /dev/secpolgenerate/policy) is added into the security policy document. The new security 
policy document is compiled using secpolcompile utility and the binary of the security policy is added into /proc/boot/
secpol.bin.

This time I do not run the command 'secpolgenerate -u -t 100' and run the dumper "on -T dumper_t /proc/boot/dumper -U 
112". 

Now the "pidin ar" command does not show the dumper running.

I believe the secpolgenerate utility generate all the abilities require by the dumper to run. But with the same 
abilities I don't see the dumper running on non-root i.e. /proc/boot/dumper -U 112 when we disable the command 
'secpolgenerate -u -t 100'.
Roger Maclean
06/27/2019 10:14 AM
post119768
Re: 'dumper' running on non-root does not work without secpogenerate   
When using secpolgenerate are you setting the environment variable LD_PRELOAD to /proc/boot/secpol-preload.so?  This is 
currently required since it provides the only way of secpolgenerate from learning what abilities a process tries to 
configure using calls to procmgr_ability.  If you don't have this, the policies it generates will lock the abilities 
which will result in the calls failing when used without secpolgenerate.

If you look at the rules in the policy for dumper_t you should find a number of rules show up as unlocked.



On 2019-06-27, 9:59 AM, "Gauresh Badve" <community-noreply@qnx.com> wrote:

    Let me explain my scenario:
    Version : QNX 7.0.0
    
    I am using secpolgenerate utility to generate security policy for the dumper. The secpolgenerate observes all the 
behavior of the dumper and creates a policy file at /dev/secpolgenerate/policy.
    
    The command I used for secpolgenerate:
    'secpolgenerate -u -t 100'
    
    I start the dumper using command:
    on -T dumper_t /proc/boot/dumper -U 112 ( Here 112 is the user id on which I want the dumper to run and dumper_t is 
the type defined for dumper in the security policy file )
    
    The "pidin ar" command shows the dumper running with user id - 112 and also the policy file generated in location /
dev/secpolgenerate/policy shows all the abilities the type dumper_t require to run the dumper.
    
    The same generated policy( at /dev/secpolgenerate/policy) is added into the security policy document. The new 
security policy document is compiled using secpolcompile utility and the binary of the security policy is added into /
proc/boot/secpol.bin.
    
    This time I do not run the command 'secpolgenerate -u -t 100' and run the dumper "on -T dumper_t /proc/boot/dumper -
U 112". 
    
    Now the "pidin ar" command does not show the dumper running.
    
    I believe the secpolgenerate utility generate all the abilities require by the dumper to run. But with the same 
abilities I don't see the dumper running on non-root i.e. /proc/boot/dumper -U 112 when we disable the command 
'secpolgenerate -u -t 100'.
    
    
    
    
    _______________________________________________
    
    General
    http://community.qnx.com/sf/go/post119767
    To cancel your subscription to this discussion, please e-mail general-community-unsubscribe@community.qnx.com
Gauresh Badve(deleted)
06/28/2019 7:41 AM
post119769
Re: 'dumper' running on non-root does not work without secpogenerate   
Thank you for the solution.

Yes the environment variable "LD_PRELOAD" was not set to /proc/boot/secpol-preload.so. After adding the following change
:
LD_PRELOAD=/proc/boot/secpol-preload.so
I could see that "pidin ar" command shows the dumper running as below

     pid Arguments
       1 procnto-smp-instr -v -mr
    8195 /proc/boot/pipe
   12292 /proc/boot/slogger2 -U 111:116
   16389 /proc/boot/dumper -U 112
   20486 /proc/boot/random -pt -U 113:105

But when I run the command " ps -e -o "user,CMD", I get the output as dumper still running on root. Please find the 
below log_1:

USER     CMD
0        procnto-smp-instr
110      pipe
111      slogger2
0        dumper
113      random

However with the secpolgenerate enabled I see that dumper running on non-root. Please find the below log_2:

USER     CMD
0        procnto-smp-instr
0        secpolgenerate
110      pipe
111      slogger2
112      dumper
113      random

Note:  The log_1 uses the same policy generated by the secpolgenerate where we see the dumper running on non-root in 
log_2.
Roger Maclean
06/28/2019 8:31 AM
post119770
Re: 'dumper' running on non-root does not work without secpogenerate   
It's not completely clear to me what you've done.  You need to set LD_PRELOAD only when you’re using secpolgenerate 
since its purpose is to communicate to secpolgenerate information about procmgr_ability calls.

Does log_1 represent the behavior when you're running the system without secpolgenerate using the generated policy?

Even if run with the -U option, dumper will run as root at times since it needs to acquire additional privileges when it
 dumps a core file.  So if you did happen to catch it after something crashed, this might be perfectly normal.


On 2019-06-28, 7:41 AM, "Gauresh Badve" <community-noreply@qnx.com> wrote:

    Thank you for the solution.
    
    Yes the environment variable "LD_PRELOAD" was not set to /proc/boot/secpol-preload.so. After adding the following 
change:
    LD_PRELOAD=/proc/boot/secpol-preload.so
    I could see that "pidin ar" command shows the dumper running as below
    
         pid Arguments
           1 procnto-smp-instr -v -mr
        8195 /proc/boot/pipe
       12292 /proc/boot/slogger2 -U 111:116
       16389 /proc/boot/dumper -U 112
       20486 /proc/boot/random -pt -U 113:105
    
    But when I run the command " ps -e -o "user,CMD", I get the output as dumper still running on root. Please find the 
below log_1:
    
    USER     CMD
    0        procnto-smp-instr
    110      pipe
    111      slogger2
    0        dumper
    113      random
    
    However with the secpolgenerate enabled I see that dumper running on non-root. Please find the below log_2:
    
    USER     CMD
    0        procnto-smp-instr
    0        secpolgenerate
    110      pipe
    111      slogger2
    112      dumper
    113      random
    
    Note:  The log_1 uses the same policy generated by the secpolgenerate where we see the dumper running on non-root in
 log_2.
    
    
    
    _______________________________________________
    
    General
    http://community.qnx.com/sf/go/post119769
    To cancel your subscription to this discussion, please e-mail general-community-unsubscribe@community.qnx.com
Gauresh Badve(deleted)
06/28/2019 9:43 AM
post119771
Re: 'dumper' running on non-root does not work without secpogenerate   
Yes log_1 represents the behavior when we are running the system without secpolgenerate. 

So here are the steps we followed:

Situation 1:

1) Enabled: LD_PRELOAD=/proc/boot/secpol-preload
                      secpolgenerate -u -t 100 

2) Give the command "pidin ar"
     I could see the following log:
   pid Arguments
       1 procnto-smp-instr -v -mr
4098 secpolgenerate -u -t 100
 8196 /proc/boot/pipe
 12293 /proc/boot/slogger2 -U 111:116
 16390 /proc/boot/dumper -U 112
 20487 /proc/boot/random -pt -U 113:105

3) Give the command "ps -e -o "user,CMD" and I see the following log:
USER     CMD
0        procnto-smp-instr
0        secpolgenerate
0        on
110      pipe
111      slogger2
112      dumper
113      random
    Here I see that the dumper is running through user ID 112.

4) Check the generated policy at /dev/secpolgenerate/policy.

Situation 2:

1) Use the policy generated from Situation 1.

2) Disabled: LD_PRELOAD=/proc/boot/secpol-preload
                      secpolgenerate -u -t 100 

3) Give the command "pidin ar".
     Here I see the following log
   pid Arguments
       1 procnto-smp-instr -v -mr
8195 /proc/boot/pipe
12292 /proc/boot/slogger2 -U 111:116
16389 /proc/boot/dumper -U 112
20486 /proc/boot/random -pt -U 113:105

4) Give the command "ps -e -o "user,CMD" and I see the following log:
USER     CMD
0        procnto-smp-instr
110      pipe
111      slogger2
0        dumper
113      random
Now I see that the dumper runs on root(UserID 0) instead of userid 112.

To check further I killed an application "kill -SIGBUS PID_of_App" but I still see the dumper running on root. 
I believe the secpolgenerate should generate the ability required to run the dumper on userid 112. Do we need to add 
some abilities manually?
Roger Maclean
06/28/2019 10:06 AM
post119772
Re: 'dumper' running on non-root does not work without secpogenerate   
Can you provide all the rules from your policy for dumper's type.

You shouldn't have to add any rules manually. Any abilities that dumper tries to configure manually should have been 
left in their default state by the policy so should behave the same with or without a security policy.  Dumper exits 
with a message to stderr if it fails to switch to the specified uid. 


On 2019-06-28, 9:43 AM, "Gauresh Badve" <community-noreply@qnx.com> wrote:

    Yes log_1 represents the behavior when we are running the system without secpolgenerate. 
    
    So here are the steps we followed:
    
    Situation 1:
    
    1) Enabled: LD_PRELOAD=/proc/boot/secpol-preload
                          secpolgenerate -u -t 100 
    
    2) Give the command "pidin ar"
         I could see the following log:
       pid Arguments
           1 procnto-smp-instr -v -mr
    4098 secpolgenerate -u -t 100
     8196 /proc/boot/pipe
     12293 /proc/boot/slogger2 -U 111:116
     16390 /proc/boot/dumper -U 112
     20487 /proc/boot/random -pt -U 113:105
    
    3) Give the command "ps -e -o "user,CMD" and I see the following log:
    USER     CMD
    0        procnto-smp-instr
    0        secpolgenerate
    0        on
    110      pipe
    111      slogger2
    112      dumper
    113      random
        Here I see that the dumper is running through user ID 112.
    
    4) Check the generated policy at /dev/secpolgenerate/policy.
    
    Situation 2:
    
    1) Use the policy generated from Situation 1.
    
    2) Disabled: LD_PRELOAD=/proc/boot/secpol-preload
                          secpolgenerate -u -t 100 
    
    3) Give the command "pidin ar".
         Here I see the following log
       pid Arguments
           1 procnto-smp-instr -v -mr
    8195 /proc/boot/pipe
    12292 /proc/boot/slogger2 -U 111:116
    16389 /proc/boot/dumper -U 112
    20486 /proc/boot/random -pt -U 113:105
    
    4) Give the command "ps -e -o "user,CMD" and I see the following log:
    USER     CMD
    0        procnto-smp-instr
    110      pipe
    111      slogger2
    0        dumper
    113      random
    Now I see that the dumper runs on root(UserID 0) instead of userid 112.
    
    To check further I killed an application "kill -SIGBUS PID_of_App" but I still see the dumper running on root. 
    I believe the secpolgenerate should generate the ability required to run the dumper on userid 112. Do we need to add
 some abilities manually?
    
    
    
    
    
    _______________________________________________
    
    General
    http://community.qnx.com/sf/go/post119771
    To cancel your subscription to this discussion, please e-mail general-community-unsubscribe@community.qnx.com
Gauresh Badve(deleted)
06/28/2019 10:33 AM
post119773
Re: 'dumper' running on non-root does not work without secpogenerate   
Please find the rules for the dumper:

# === Rules for type dumper_t ============
allow_attach dumper_t {
    /proc/dumper
};
allow dumper_t self:ability {
    unlock  noinherit
    # allow all
    setuid
    # allow all
    setgid
    # allow nonroot
    mem_peer
    # allow all
    priority
    # allow root
    able_priv
};
allow dumper_t self:ability {
    pathspace
    prot_exec
    map_fixed
    public_channel
    prot_write_and_exec
};
allow dumper_t self:ability {
    channel_connect:slogger2_t,devb_t
    xprocess_mem_read:100
};
Roger Maclean
06/28/2019 4:22 PM
post119774
Re: 'dumper' running on non-root does not work without secpogenerate   
I tried it and dumper seems to run with the write uid.  I'm not sure if I'm running exactly the same version as you but 
I suspect it doesn't matter.

Looking into dumper code, it appears that there is a bug which could cause this.  You'll see the policy includes:

    xprocess_mem_read:100

this is what allows dumper to read the memory of the process that it generates a core file for.  However it is subranged
 by uid so in this case it has been given the ability only to dump processes with a uid of 100.  If a process with a 
different uid crashes, dumper switches to uid 0 to dump it's memory.  This however fails and dumper gives up but in 
doing so neglects to switch back.

If this is the case, if you remove the ':100' from xprocess_mem_read in the policy the issue might go away.  This is 
actually one of the cases where you do tend to have to alter the policy generated by secpolgenerate.  Secpolgenerate 
tries to give the minimal abilities which is appropriate in most cases but there are some exceptions.



On 2019-06-28, 10:33 AM, "Gauresh Badve" <community-noreply@qnx.com> wrote:

    Please find the rules for the dumper:
    
    # === Rules for type dumper_t ============
    allow_attach dumper_t {
        /proc/dumper
    };
    allow dumper_t self:ability {
        unlock  noinherit
        # allow all
        setuid
        # allow all
        setgid
        # allow nonroot
        mem_peer
        # allow all
        priority
        # allow root
        able_priv
    };
    allow dumper_t self:ability {
        pathspace
        prot_exec
        map_fixed
        public_channel
        prot_write_and_exec
    };
    allow dumper_t self:ability {
        channel_connect:slogger2_t,devb_t
        xprocess_mem_read:100
    };
    
    
    
    
    _______________________________________________
    
    General
    http://community.qnx.com/sf/go/post119773
    To cancel your subscription to this discussion, please e-mail general-community-unsubscribe@community.qnx.com

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems