Security modules and sending signals within the same process

Security modules and sending signals within the same process

[Florian Weimer]

Is it guaranteed that tasks in the same thread group can always send
signals to each other, irrespective of their respective credentials
structs?

It's not clear to me whether this is always possible based on the
security_task_kill implementations I've examined.

I want to support per-thread setresuid/setresgid, but we also use
signals for inter-thread communication.  This is mainly for thread
cancellation; the setxgid stuff isn't needed for threads with private
credentials.  I wonder if I need to disable cancellation for threads
with such credentials.

Thanks,
Florian

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor

Security modules and sending signals within the same process

[Florian Weimer]

Is it guaranteed that tasks in the same thread group can always send
signals to each other, irrespective of their respective credentials
structs?

It's not clear to me whether this is always possible based on the
security_task_kill implementations I've examined.

I want to support per-thread setresuid/setresgid, but we also use
signals for inter-thread communication.  This is mainly for thread
cancellation; the setxgid stuff isn't needed for threads with private
credentials.  I wonder if I need to disable cancellation for threads
with such credentials.

Thanks,
Florian

Re: Security modules and sending signals within the same process

[Stephen Smalley]

On 11/30/18 10:14 AM, Florian Weimer wrote:
> Is it guaranteed that tasks in the same thread group can always send
> signals to each other, irrespective of their respective credentials
> structs?
> 
> It's not clear to me whether this is always possible based on the
> security_task_kill implementations I've examined.
> 
> I want to support per-thread setresuid/setresgid, but we also use
> signals for inter-thread communication.  This is mainly for thread
> cancellation; the setxgid stuff isn't needed for threads with private
> credentials.  I wonder if I need to disable cancellation for threads
> with such credentials.

(fixed selinux list address, which moved to vger)

Looks like commit 065add3941bd ("signals: check_kill_permission(): don't 
check creds if same_thread_group()") skipped the uid-based checks if the 
sender and target were in the same thread group, but not the security 
hook call.  One could argue that the security hook call ought to be 
skipped in that case as well using the same rationale given in that 
commit.  Nothing appears to guarantee the property you state above for 
security_task_kill implementations, although none of the in-tree users 
are based on uids or gids so setresuid/setresgid shouldn't affect them.

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: Security modules and sending signals within the same process

[Stephen Smalley]

On 11/30/18 10:14 AM, Florian Weimer wrote:
> Is it guaranteed that tasks in the same thread group can always send
> signals to each other, irrespective of their respective credentials
> structs?
> 
> It's not clear to me whether this is always possible based on the
> security_task_kill implementations I've examined.
> 
> I want to support per-thread setresuid/setresgid, but we also use
> signals for inter-thread communication.  This is mainly for thread
> cancellation; the setxgid stuff isn't needed for threads with private
> credentials.  I wonder if I need to disable cancellation for threads
> with such credentials.

(fixed selinux list address, which moved to vger)

Looks like commit 065add3941bd ("signals: check_kill_permission(): don't 
check creds if same_thread_group()") skipped the uid-based checks if the 
sender and target were in the same thread group, but not the security 
hook call.  One could argue that the security hook call ought to be 
skipped in that case as well using the same rationale given in that 
commit.  Nothing appears to guarantee the property you state above for 
security_task_kill implementations, although none of the in-tree users 
are based on uids or gids so setresuid/setresgid shouldn't affect them.

Re: Security modules and sending signals within the same process

[Florian Weimer]

* Stephen Smalley:

> Looks like commit 065add3941bd ("signals: check_kill_permission():
> don't check creds if same_thread_group()") skipped the uid-based
> checks if the sender and target were in the same thread group, but not
> the security hook call.  One could argue that the security hook call
> ought to be skipped in that case as well using the same rationale
> given in that commit.  Nothing appears to guarantee the property you
> state above for security_task_kill implementations, although none of
> the in-tree users are based on uids or gids so setresuid/setresgid
> shouldn't affect them.

Okay, thanks, so it looks like I don't have to do anything special to
support thread cancellation.

Florian

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: Security modules and sending signals within the same process

[Florian Weimer]

* Stephen Smalley:

> Looks like commit 065add3941bd ("signals: check_kill_permission():
> don't check creds if same_thread_group()") skipped the uid-based
> checks if the sender and target were in the same thread group, but not
> the security hook call.  One could argue that the security hook call
> ought to be skipped in that case as well using the same rationale
> given in that commit.  Nothing appears to guarantee the property you
> state above for security_task_kill implementations, although none of
> the in-tree users are based on uids or gids so setresuid/setresgid
> shouldn't affect them.

Okay, thanks, so it looks like I don't have to do anything special to
support thread cancellation.

Florian

Re: Security modules and sending signals within the same process

[Casey Schaufler]

On 11/30/2018 7:14 AM, Florian Weimer wrote:
> Is it guaranteed that tasks in the same thread group can always send
> signals to each other, irrespective of their respective credentials
> structs?

No. An LSM may chose to disallow this based on just about any
criteria it desires.

> It's not clear to me whether this is always possible based on the
> security_task_kill implementations I've examined.

SELinux, Smack and AppArmor make their decisions based on
the task_struct credential, so if it's possible to change
the LSM attributes at the task granularity, it's possible
to have a process that can't always talk to itself.

> I want to support per-thread setresuid/setresgid,

That's pretty dangerous in its own right. Effectively
the process containing the threads has multiple UIDs.
That complicates the DAC model significantly.

> but we also use
> signals for inter-thread communication.

It's unfortunate that no one has seriously proposed
mode bits on processes for signal delivery. The UID
matching policy is inconvenient in a lot of cases.
Hmmm...

> This is mainly for thread
> cancellation; the setxgid stuff isn't needed for threads with private
> credentials.  I wonder if I need to disable cancellation for threads
> with such credentials.
>
> Thanks,
> Florian
>


-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: Security modules and sending signals within the same process

[Casey Schaufler]

On 11/30/2018 7:14 AM, Florian Weimer wrote:
> Is it guaranteed that tasks in the same thread group can always send
> signals to each other, irrespective of their respective credentials
> structs?

No. An LSM may chose to disallow this based on just about any
criteria it desires.

> It's not clear to me whether this is always possible based on the
> security_task_kill implementations I've examined.

SELinux, Smack and AppArmor make their decisions based on
the task_struct credential, so if it's possible to change
the LSM attributes at the task granularity, it's possible
to have a process that can't always talk to itself.

> I want to support per-thread setresuid/setresgid,

That's pretty dangerous in its own right. Effectively
the process containing the threads has multiple UIDs.
That complicates the DAC model significantly.

> but we also use
> signals for inter-thread communication.

It's unfortunate that no one has seriously proposed
mode bits on processes for signal delivery. The UID
matching policy is inconvenient in a lot of cases.
Hmmm...

> This is mainly for thread
> cancellation; the setxgid stuff isn't needed for threads with private
> credentials.  I wonder if I need to disable cancellation for threads
> with such credentials.
>
> Thanks,
> Florian
>

Re: Security modules and sending signals within the same process

[Florian Weimer]

* Casey Schaufler:

> On 11/30/2018 7:14 AM, Florian Weimer wrote:
>> Is it guaranteed that tasks in the same thread group can always send
>> signals to each other, irrespective of their respective credentials
>> structs?
>
> No. An LSM may chose to disallow this based on just about any
> criteria it desires.

Hmm.

>> It's not clear to me whether this is always possible based on the
>> security_task_kill implementations I've examined.
>
> SELinux, Smack and AppArmor make their decisions based on
> the task_struct credential, so if it's possible to change
> the LSM attributes at the task granularity, it's possible
> to have a process that can't always talk to itself.

Yes, we already have this today for LSM attributes.  We only paper over
this for the UIDs/GIDs, using a really awkward mechanism.  Maybe we will
get rid of that one day, when the kernel supports a proper per-process
attribute, but I don't count on it.

>> I want to support per-thread setresuid/setresgid,
>
> That's pretty dangerous in its own right. Effectively
> the process containing the threads has multiple UIDs.
> That complicates the DAC model significantly.

Sure.  But I think it's better to do this explicitly in glibc, rather
than file server authors calling the system calls directly.  And it only
exposes what the kernel does anyway.

Thanks,
Florian

-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: Security modules and sending signals within the same process

[Florian Weimer]

* Casey Schaufler:

> On 11/30/2018 7:14 AM, Florian Weimer wrote:
>> Is it guaranteed that tasks in the same thread group can always send
>> signals to each other, irrespective of their respective credentials
>> structs?
>
> No. An LSM may chose to disallow this based on just about any
> criteria it desires.

Hmm.

>> It's not clear to me whether this is always possible based on the
>> security_task_kill implementations I've examined.
>
> SELinux, Smack and AppArmor make their decisions based on
> the task_struct credential, so if it's possible to change
> the LSM attributes at the task granularity, it's possible
> to have a process that can't always talk to itself.

Yes, we already have this today for LSM attributes.  We only paper over
this for the UIDs/GIDs, using a really awkward mechanism.  Maybe we will
get rid of that one day, when the kernel supports a proper per-process
attribute, but I don't count on it.

>> I want to support per-thread setresuid/setresgid,
>
> That's pretty dangerous in its own right. Effectively
> the process containing the threads has multiple UIDs.
> That complicates the DAC model significantly.

Sure.  But I think it's better to do this explicitly in glibc, rather
than file server authors calling the system calls directly.  And it only
exposes what the kernel does anyway.

Thanks,
Florian

Re: Security modules and sending signals within the same process

[John Johansen]

On 11/30/18 9:54 AM, Casey Schaufler wrote:
> On 11/30/2018 7:14 AM, Florian Weimer wrote:
>> Is it guaranteed that tasks in the same thread group can always send
>> signals to each other, irrespective of their respective credentials
>> structs?
> 
> No. An LSM may chose to disallow this based on just about any
> criteria it desires.
> 

And apparmor is in fact doing this a few limited situations, userspace
has to request the profile change via an api, and regular policy
enforcement based on credentials mediates the signals. Its not
something we recommend but it has been used.



-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor

Re: [apparmor] Security modules and sending signals within the same process

[John Johansen]

On 11/30/18 9:54 AM, Casey Schaufler wrote:
> On 11/30/2018 7:14 AM, Florian Weimer wrote:
>> Is it guaranteed that tasks in the same thread group can always send
>> signals to each other, irrespective of their respective credentials
>> structs?
> 
> No. An LSM may chose to disallow this based on just about any
> criteria it desires.
> 

And apparmor is in fact doing this a few limited situations, userspace
has to request the profile change via an api, and regular policy
enforcement based on credentials mediates the signals. Its not
something we recommend but it has been used.