Regarding pledge system call bit value for a non-pledged process

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Regarding pledge system call bit value for a non-pledged process

neerajpal
Hello guys,

#pledge_queries

I have a query regarding #pledge internals.

I read kern_pledge.c file, but, I am not able to figure out the pledge
bit value of a program which isn't using pledge() system call in
user-space code.
Because even after not using pledge() system call in user-space,
still, every process has some default kind of pledge bit value, that
is, 0x8009588f.

Find pledge details of dhclient and slaacd process:

# dmesg|grep dhclient

old_pledge: 8009588f new_pledge: 101068 pid: 4970 name: dhclient
pledge_xbit: 8009588f
old_pledge: 8009588f new_pledge: 101068 pid: 880 name: dhclient
pledge_xbit: 8009588f

# dmesg|grep slaacd

old_pledge: 8009588f new_pledge: 40008 pid: 20726 name: slaacd
pledge_xbit: 8009588f
old_pledge: 8009588f new_pledge: 140048 pid: 32909 name: slaacd
pledge_xbit: 8009588f
old_pledge: 140048 new_pledge: 100048 pid: 32909 name: slaacd
pledge_xbit: 140048
old_pledge: 40008 new_pledge: 8 pid: 20726 name: slaacd pledge_xbit: 40008

And, for verification, I have written two small codes and I tested them:

//sample1
//without pledge()
#include <stdio.h>

void
main () {
while(1) {}
}

//sample2
//with pledge()
#include <stdio.h>

void
main () {
if(pledge("stdio",NULL) == -1) {
err(1,"pledge");
}
while(1) {}
}

Now, both codes have some pledge bit value, that is, for sample2
pledge_bit value is 8 which is correct, but, for sample1 pledge_bit
value is 0x8009588f.
whereas, in sample1 no one is calling pledge() system call then also
it has some pledge value.
And, I don't know why every non-pledge process has only this value.
It seems like there is some default pledge value for every process.

So, please guys give me some hint or update me on something if I
forgot or missed.


--
Thank you,

Neeraj Pal

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

Stuart Henderson
On 2018/02/18 12:36, Neeraj Pal wrote:
> I read kern_pledge.c file, but, I am not able to figure out the pledge
> bit value of a program which isn't using pledge() system call in
> user-space code.
> Because even after not using pledge() system call in user-space,
> still, every process has some default kind of pledge bit value, that
> is, 0x8009588f.

ps_pledge only indicates that a process has been pledged if the PS_PLEDGE
bit (0x00100000) has been set.

On a new process this bit (and this bit only) is cleared explicitly by
atomic_clearbits_int in sys/kern_exec.c:sys_execve(), I haven't looked
further but presumably other bits are just as returned from the allocator.

Basically if you are looking to see what pledge a process has, check
PS_PLEDGE first, other bits are only meaningful if that bit is set.

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

neerajpal
Okay. So, you told me that If I need to check which process pledge
what, then I need to first check PS_PLEDGE bit
is set or not because it indicates whether a pledge called or not in a process.

But, what I asked is, if the pledge is not even called in userspace
code of any process, let's take an example of sample1 code
that I sent, then from where and how kernel computes this, 0x8009588f
pledge bit value.



On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <[hidden email]> wrote:

> On 2018/02/18 12:36, Neeraj Pal wrote:
>> I read kern_pledge.c file, but, I am not able to figure out the pledge
>> bit value of a program which isn't using pledge() system call in
>> user-space code.
>> Because even after not using pledge() system call in user-space,
>> still, every process has some default kind of pledge bit value, that
>> is, 0x8009588f.
>
> ps_pledge only indicates that a process has been pledged if the PS_PLEDGE
> bit (0x00100000) has been set.
>
> On a new process this bit (and this bit only) is cleared explicitly by
> atomic_clearbits_int in sys/kern_exec.c:sys_execve(), I haven't looked
> further but presumably other bits are just as returned from the allocator.
>
> Basically if you are looking to see what pledge a process has, check
> PS_PLEDGE first, other bits are only meaningful if that bit is set.
>



--
Thank you,

Neeraj Pal ツ
 +91-8130344470

The information contents contained in this electronic communication
(including the contents of the enclosure(s) or attachment(s) if any)
is intended exclusively and solely for the individual(s) or entity to
which it is addressed and may contain information that is private,
confidential, legally privileged material and exempted from
disclosure. Any review, re transmission, dissemination, printing,
copying or other use of, or taking any action in reliance on the
contents of this information by person(s) or entities other than the
intended recipient is strictly prohibited and may be unlawful. If you
have received this communication in error, please notify by responding
to this email or telephone and immediately and permanently delete all
copies of this message and any attachments from your systems.

This footnote confirms that this email message has been scanned  for
the presence of malicious code, vandals & computer viruses. The
recipient should check this email and any attachments for the presence
of viruses.

Please consider the environment before printing this email.

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

neerajpal
In reply to this post by Stuart Henderson
On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <[hidden email]> wrote:

> On 2018/02/18 12:36, Neeraj Pal wrote:
>> I read kern_pledge.c file, but, I am not able to figure out the pledge
>> bit value of a program which isn't using pledge() system call in
>> user-space code.
>> Because even after not using pledge() system call in user-space,
>> still, every process has some default kind of pledge bit value, that
>> is, 0x8009588f.
>
> ps_pledge only indicates that a process has been pledged if the PS_PLEDGE
> bit (0x00100000) has been set.
>
> On a new process this bit (and this bit only) is cleared explicitly by
> atomic_clearbits_int in sys/kern_exec.c:sys_execve(), I haven't looked
> further but presumably other bits are just as returned from the allocator.
>
> Basically if you are looking to see what pledge a process has, check
> PS_PLEDGE first, other bits are only meaningful if that bit is set.
>

Okay. So, you told me that If I need to check which process pledge
what, then I need to first check PS_PLEDGE bit
is set or not because it indicates whether a pledge called or not in a process.

But, what I asked is, if the pledge is not even called in userspace
code of any process, let's take an example of sample1 code
that I sent, then from where and how kernel computes this, 0x8009588f
pledge bit value.






--
Thank you,

Neeraj Pal

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

neerajpal
In reply to this post by Stuart Henderson
Okay. So, you told me that If I need to check which process pledge
what, then I need to first check PS_PLEDGE bit
is set or not because it indicates whether a pledge called or not in a process.

But, what I asked is, if the pledge is not even called in userspace
code of any process, let's take an example of sample1 code
that I sent, then from where and how kernel computes this, 0x8009588f
pledge bit value.

On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <[hidden email]> wrote:

> On 2018/02/18 12:36, Neeraj Pal wrote:
>> I read kern_pledge.c file, but, I am not able to figure out the pledge
>> bit value of a program which isn't using pledge() system call in
>> user-space code.
>> Because even after not using pledge() system call in user-space,
>> still, every process has some default kind of pledge bit value, that
>> is, 0x8009588f.
>
> ps_pledge only indicates that a process has been pledged if the PS_PLEDGE
> bit (0x00100000) has been set.
>
> On a new process this bit (and this bit only) is cleared explicitly by
> atomic_clearbits_int in sys/kern_exec.c:sys_execve(), I haven't looked
> further but presumably other bits are just as returned from the allocator.
>
> Basically if you are looking to see what pledge a process has, check
> PS_PLEDGE first, other bits are only meaningful if that bit is set.
>

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

Stuart Henderson
In reply to this post by neerajpal
On 2018/02/18 20:00, Neeraj Pal wrote:
> Okay. So, you told me that If I need to check which process pledge
> what, then I need to first check PS_PLEDGE bit
> is set or not because it indicates whether a pledge called or not in a process.
>
> But, what I asked is, if the pledge is not even called in userspace
> code of any process, let's take an example of sample1 code
> that I sent, then from where and how kernel computes this, 0x8009588f
> pledge bit value.

It isn't computed. Other than the PS_PLEDGE bit, the memory in ps_pledge
is uninitialized.

>
>
> On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <[hidden email]> wrote:
> > On 2018/02/18 12:36, Neeraj Pal wrote:
> >> I read kern_pledge.c file, but, I am not able to figure out the pledge
> >> bit value of a program which isn't using pledge() system call in
> >> user-space code.
> >> Because even after not using pledge() system call in user-space,
> >> still, every process has some default kind of pledge bit value, that
> >> is, 0x8009588f.
> >
> > ps_pledge only indicates that a process has been pledged if the PS_PLEDGE
> > bit (0x00100000) has been set.
> >
> > On a new process this bit (and this bit only) is cleared explicitly by
> > atomic_clearbits_int in sys/kern_exec.c:sys_execve(), I haven't looked
> > further but presumably other bits are just as returned from the allocator.
> >
> > Basically if you are looking to see what pledge a process has, check
> > PS_PLEDGE first, other bits are only meaningful if that bit is set.
> >
>
>
>
> --
> Thank you,
>
> Neeraj Pal ツ
>  +91-8130344470
>
> The information contents contained in this electronic communication
> (including the contents of the enclosure(s) or attachment(s) if any)
> is intended exclusively and solely for the individual(s) or entity to
> which it is addressed and may contain information that is private,
> confidential, legally privileged material and exempted from
> disclosure. Any review, re transmission, dissemination, printing,
> copying or other use of, or taking any action in reliance on the
> contents of this information by person(s) or entities other than the
> intended recipient is strictly prohibited and may be unlawful. If you
> have received this communication in error, please notify by responding
> to this email or telephone and immediately and permanently delete all
> copies of this message and any attachments from your systems.
>
> This footnote confirms that this email message has been scanned  for
> the presence of malicious code, vandals & computer viruses. The
> recipient should check this email and any attachments for the presence
> of viruses.
>
> Please consider the environment before printing this email.
>

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

neerajpal
yeah, but I am asking about pledge_xbit (pledge value of any process
in hex). See output:

process name: pltestnopledge(no pledge)            ps_flags:
101007 kern_exec:     100000 pid:      66364 pledge_xbit:   8009588f

process name: pltest(with pledge("stdio",NULL))  ps_flags:     101007
kern_exec:     100000 pid:      74005 pledge_xbit:                8

Now, 2nd line is correct, because of pledge "stdio" and PLEDGE_STDIO
is 0x0000000000000008, but I am confused with 1st line. How it becomes
even this, 0x8009588f value without pledge.

Sorry, but I think either I am not getting you or you didn't get my question.

I don't know why you are telling me about PS_PLEDGE because I know
that when PS_PLEDGE is set, then it means the process has called
pledge.

We can do this to check whether any process has called pledged or not:

if ((p->p_p->ps_pledge & PS_PLEDGE) > 0) {

        /* pledged process */
}
else {

        /* unpledged process */
}

But, I am confused with this specific value, from where it came, what
logic it takes to come. Like in case of the pledged process we can
calculate their pledge values by doing "or" between permissions like
"stdio inet"  etc.






On Sun, Feb 18, 2018 at 8:45 PM, Stuart Henderson <[hidden email]> wrote:

> On 2018/02/18 20:00, Neeraj Pal wrote:
>> Okay. So, you told me that If I need to check which process pledge
>> what, then I need to first check PS_PLEDGE bit
>> is set or not because it indicates whether a pledge called or not in a process.
>>
>> But, what I asked is, if the pledge is not even called in userspace
>> code of any process, let's take an example of sample1 code
>> that I sent, then from where and how kernel computes this, 0x8009588f
>> pledge bit value.
>
> It isn't computed. Other than the PS_PLEDGE bit, the memory in ps_pledge
> is uninitialized.
>
>>
>>
>> On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <[hidden email]> wrote:
>> > On 2018/02/18 12:36, Neeraj Pal wrote:
>> >> I read kern_pledge.c file, but, I am not able to figure out the pledge
>> >> bit value of a program which isn't using pledge() system call in
>> >> user-space code.
>> >> Because even after not using pledge() system call in user-space,
>> >> still, every process has some default kind of pledge bit value, that
>> >> is, 0x8009588f.
>> >
>> > ps_pledge only indicates that a process has been pledged if the PS_PLEDGE
>> > bit (0x00100000) has been set.
>> >
>> > On a new process this bit (and this bit only) is cleared explicitly by
>> > atomic_clearbits_int in sys/kern_exec.c:sys_execve(), I haven't looked
>> > further but presumably other bits are just as returned from the allocator.
>> >
>> > Basically if you are looking to see what pledge a process has, check
>> > PS_PLEDGE first, other bits are only meaningful if that bit is set.
>> >
>>
>>
>>
>> --
>> Thank you,
>>
>> Neeraj Pal ツ
>>  +91-8130344470
>>
>> The information contents contained in this electronic communication
>> (including the contents of the enclosure(s) or attachment(s) if any)
>> is intended exclusively and solely for the individual(s) or entity to
>> which it is addressed and may contain information that is private,
>> confidential, legally privileged material and exempted from
>> disclosure. Any review, re transmission, dissemination, printing,
>> copying or other use of, or taking any action in reliance on the
>> contents of this information by person(s) or entities other than the
>> intended recipient is strictly prohibited and may be unlawful. If you
>> have received this communication in error, please notify by responding
>> to this email or telephone and immediately and permanently delete all
>> copies of this message and any attachments from your systems.
>>
>> This footnote confirms that this email message has been scanned  for
>> the presence of malicious code, vandals & computer viruses. The
>> recipient should check this email and any attachments for the presence
>> of viruses.
>>
>> Please consider the environment before printing this email.
>>

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

Otto Moerbeek
On Sun, Feb 18, 2018 at 09:19:12PM +0530, Neeraj Pal wrote:

> yeah, but I am asking about pledge_xbit (pledge value of any process
> in hex). See output:
>
> process name: pltestnopledge(no pledge)            ps_flags:
> 101007 kern_exec:     100000 pid:      66364 pledge_xbit:   8009588f
>
> process name: pltest(with pledge("stdio",NULL))  ps_flags:     101007
> kern_exec:     100000 pid:      74005 pledge_xbit:                8
>
> Now, 2nd line is correct, because of pledge "stdio" and PLEDGE_STDIO
> is 0x0000000000000008, but I am confused with 1st line. How it becomes
> even this, 0x8009588f value without pledge.
>
> Sorry, but I think either I am not getting you or you didn't get my question.
>
> I don't know why you are telling me about PS_PLEDGE because I know
> that when PS_PLEDGE is set, then it means the process has called
> pledge.
>
> We can do this to check whether any process has called pledged or not:
>
> if ((p->p_p->ps_pledge & PS_PLEDGE) > 0) {
>
>         /* pledged process */
> }
> else {
>
>         /* unpledged process */
> }

No, that is not correct. ps_pledge is only valid if PS_PLEDGE is set
in ps_flags. Something like:

pledge_bits = (p->p_p->ps_flags & PS_PLEDGE) ? p->p_p->ps_pledge : 0

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

Stuart Henderson
In reply to this post by neerajpal
On 2018/02/18 21:19, Neeraj Pal wrote:

> yeah, but I am asking about pledge_xbit (pledge value of any process
> in hex). See output:
>
> process name: pltestnopledge(no pledge)            ps_flags:
> 101007 kern_exec:     100000 pid:      66364 pledge_xbit:   8009588f
>
> process name: pltest(with pledge("stdio",NULL))  ps_flags:     101007
> kern_exec:     100000 pid:      74005 pledge_xbit:                8
>
> Now, 2nd line is correct, because of pledge "stdio" and PLEDGE_STDIO
> is 0x0000000000000008, but I am confused with 1st line. How it becomes
> even this, 0x8009588f value without pledge.
>
> Sorry, but I think either I am not getting you or you didn't get my question.
>
> I don't know why you are telling me about PS_PLEDGE because I know
> that when PS_PLEDGE is set, then it means the process has called
> pledge.

I am telling you this, because if the PS_PLEDGE bit in ps_pledge is
not set, the other bits in ps_pledge are NOT VALID.

(I don't know what pledge_xbit is, it's not in the kernel.
Something you've added?)

If you want to know more than this you will need to look at how
kernel memory allocation works.

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

Stuart Henderson
On 2018/02/18 16:25, Stuart Henderson wrote:

> On 2018/02/18 21:19, Neeraj Pal wrote:
> > yeah, but I am asking about pledge_xbit (pledge value of any process
> > in hex). See output:
> >
> > process name: pltestnopledge(no pledge)            ps_flags:
> > 101007 kern_exec:     100000 pid:      66364 pledge_xbit:   8009588f
> >
> > process name: pltest(with pledge("stdio",NULL))  ps_flags:     101007
> > kern_exec:     100000 pid:      74005 pledge_xbit:                8
> >
> > Now, 2nd line is correct, because of pledge "stdio" and PLEDGE_STDIO
> > is 0x0000000000000008, but I am confused with 1st line. How it becomes
> > even this, 0x8009588f value without pledge.
> >
> > Sorry, but I think either I am not getting you or you didn't get my question.
> >
> > I don't know why you are telling me about PS_PLEDGE because I know
> > that when PS_PLEDGE is set, then it means the process has called
> > pledge.
>
> I am telling you this, because if the PS_PLEDGE bit in ps_pledge is
> not set, the other bits in ps_pledge are NOT VALID.

Ah sorry, Otto is right, PS_PLEDGE bit in ps_flags.

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

neerajpal
Yeah, Stuart told me about PS_PLEDGE, sorry I don't know how I forgot.
And, yes, pledge_xbit is nothing in the kernel, I just added a random
string for output.

Thanks for clarification Otto.

So, just for printing out values, I have changed sched_bsd.c code.


# diff -u sched_bsd.c sys/kern/sched_bsd.c
--- sched_bsd.c Sun Feb 18 21:53:54 2018
+++ sys/kern/sched_bsd.c        Sun Feb 18 21:35:08 2018
@@ -217,6 +217,15 @@
        KASSERT(phz);

        LIST_FOREACH(p, &allproc, p_list) {
+
+               if((p->p_p->ps_flags & PS_PLEDGE) > 0) {
+                       printf("flags: %10x pid: %10d name: %5s
pledge_bit: %10llx\n",p->p_p->ps_flags,p->p_p->ps_pid,p->p_p->ps_comm,p->p_p->ps_pledge);
+
+               }
+               else{
+
+                       printf("flags: %10x pid: %10d name: %5s
pledge_bit: %10llx\n",p->p_p->ps_flags,p->p_p->ps_pid,p->p_p->ps_comm,p->p_p->ps_pledge);
+               }
                /*
                 * Increment sleep time (if sleeping). We ignore overflow.
                 */
#


dmesg output:

# ./pltestnopledge  &
[1] 94834       #without pledge
# ./pltest &
[2] 33241       #with pledge
# dmesg|grep plt
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
flags:     100003                pid:      33241 name: pltest
      pledge_bit:          8
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
flags:     100003                pid:      33241 name: pltest
      pledge_bit:          8
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
flags:     100003                pid:      33241 name: pltest
      pledge_bit:          8
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
flags:     100003                pid:      33241 name: pltest
      pledge_bit:          8
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
flags:     100003                pid:      33241 name: pltest
      pledge_bit:          8
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
flags:     100003                pid:      33241 name: pltest
      pledge_bit:          8
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
flags:     100003                pid:      33241 name: pltest
      pledge_bit:          8
flags:          3                     pid:      94834 name:
pltestnopledge pledge_bit:   8009588f
#

Now, also, there is 0x8009588f for the non-pledged process.

Now, Is it correct?

On Sun, Feb 18, 2018 at 9:58 PM, Stuart Henderson <[hidden email]> wrote:

> On 2018/02/18 16:25, Stuart Henderson wrote:
>> On 2018/02/18 21:19, Neeraj Pal wrote:
>> > yeah, but I am asking about pledge_xbit (pledge value of any process
>> > in hex). See output:
>> >
>> > process name: pltestnopledge(no pledge)            ps_flags:
>> > 101007 kern_exec:     100000 pid:      66364 pledge_xbit:   8009588f
>> >
>> > process name: pltest(with pledge("stdio",NULL))  ps_flags:     101007
>> > kern_exec:     100000 pid:      74005 pledge_xbit:                8
>> >
>> > Now, 2nd line is correct, because of pledge "stdio" and PLEDGE_STDIO
>> > is 0x0000000000000008, but I am confused with 1st line. How it becomes
>> > even this, 0x8009588f value without pledge.
>> >
>> > Sorry, but I think either I am not getting you or you didn't get my question.
>> >
>> > I don't know why you are telling me about PS_PLEDGE because I know
>> > that when PS_PLEDGE is set, then it means the process has called
>> > pledge.
>>
>> I am telling you this, because if the PS_PLEDGE bit in ps_pledge is
>> not set, the other bits in ps_pledge are NOT VALID.
>
> Ah sorry, Otto is right, PS_PLEDGE bit in ps_flags.

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

Stuart Henderson
In reply to this post by neerajpal
On 2018/02/18 20:05, Neeraj Pal wrote:

> On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <[hidden email]> wrote:
> > On 2018/02/18 12:36, Neeraj Pal wrote:
> >> I read kern_pledge.c file, but, I am not able to figure out the pledge
> >> bit value of a program which isn't using pledge() system call in
> >> user-space code.
> >> Because even after not using pledge() system call in user-space,
> >> still, every process has some default kind of pledge bit value, that
> >> is, 0x8009588f.
> >
> > ps_pledge only indicates that a process has been pledged if the PS_PLEDGE
> > bit (0x00100000) has been set.
> >
> > On a new process this bit (and this bit only) is cleared explicitly by
> > atomic_clearbits_int in sys/kern_exec.c:sys_execve(), I haven't looked
> > further but presumably other bits are just as returned from the allocator.
> >
> > Basically if you are looking to see what pledge a process has, check
> > PS_PLEDGE first, other bits are only meaningful if that bit is set.
> >
>
> Okay. So, you told me that If I need to check which process pledge
> what, then I need to first check PS_PLEDGE bit
> is set or not because it indicates whether a pledge called or not in a process.
>
> But, what I asked is, if the pledge is not even called in userspace
> code of any process, let's take an example of sample1 code
> that I sent, then from where and how kernel computes this, 0x8009588f
> pledge bit value.

If you want to know more about where the exact value of a not-initialized
ps_pledge comes from, you'll need to follow through process creation system
calls.

I'm not going to do that for you because the actual value in ps_pledge
for an unpledged program is meaningless anyway.

Reply | Threaded
Open this post in threaded view
|

Re: Regarding pledge system call bit value for a non-pledged process

neerajpal
Yeah, you are right. And, I am not telling anyone to do that for me.

I had asked just because of curiosity that how a non-pledged process
has some fixed pledge value.

I thought someone already knows about that.


Thank you for help :)

On Mon, Feb 19, 2018 at 3:02 AM, Stuart Henderson <[hidden email]> wrote:

> On 2018/02/18 20:05, Neeraj Pal wrote:
>> On Sun, Feb 18, 2018 at 6:21 PM, Stuart Henderson <[hidden email]> wrote:
>> > On 2018/02/18 12:36, Neeraj Pal wrote:
>> >> I read kern_pledge.c file, but, I am not able to figure out the pledge
>> >> bit value of a program which isn't using pledge() system call in
>> >> user-space code.
>> >> Because even after not using pledge() system call in user-space,
>> >> still, every process has some default kind of pledge bit value, that
>> >> is, 0x8009588f.
>> >
>> > ps_pledge only indicates that a process has been pledged if the PS_PLEDGE
>> > bit (0x00100000) has been set.
>> >
>> > On a new process this bit (and this bit only) is cleared explicitly by
>> > atomic_clearbits_int in sys/kern_exec.c:sys_execve(), I haven't looked
>> > further but presumably other bits are just as returned from the allocator.
>> >
>> > Basically if you are looking to see what pledge a process has, check
>> > PS_PLEDGE first, other bits are only meaningful if that bit is set.
>> >
>>
>> Okay. So, you told me that If I need to check which process pledge
>> what, then I need to first check PS_PLEDGE bit
>> is set or not because it indicates whether a pledge called or not in a process.
>>
>> But, what I asked is, if the pledge is not even called in userspace
>> code of any process, let's take an example of sample1 code
>> that I sent, then from where and how kernel computes this, 0x8009588f
>> pledge bit value.
>
> If you want to know more about where the exact value of a not-initialized
> ps_pledge comes from, you'll need to follow through process creation system
> calls.
>
> I'm not going to do that for you because the actual value in ps_pledge
> for an unpledged program is meaningless anyway.
>