On gio, 2014-03-27 at 08:58 -0700, Casey Schaufler wrote:
On 3/27/2014 2:28 AM, José Bollo wrote:
> Hi Casey,
>
> That simple patch makes load-self(2) being continuously restrictive,
> what means that dropped rights aren't recoverable without having
> CAP_MAC_ADMIN.
>
> As you know, this "self" restriction rules are inherited by processes
> after exec and copied by fork. Then having that modification would allow
> smack aware applications to trust that the restrictions they made for
> themselfs, for their subcomponents or for their subprocesses are
> respected.
>
> What do you think of it?
It breaks compatibility with the original intent of load-self,
which works together with SMACK64MMAP to ensure that libraries
are safe to use in particular circumstances. It's not used in
Tizen, but it was under development in MeeGo and may be being
used in the field.
Interesting, do you have some precise links on examples of that usage? I
would like to check and understand more deeply.
NAK
ACK
Best regards
José
>
> Best regards
> José
>
> diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
> index 160aa08..9b71ee5 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -210,7 +210,8 @@ static int smk_set_access(struct smack_parsed_rule
> *srp,
> if (sp->smk_object == srp->smk_object &&
> sp->smk_subject == srp->smk_subject) {
> found = 1;
> - sp->smk_access |= srp->smk_access1;
> + if (global || smack_privileged(CAP_MAC_ADMIN))
> + sp->smk_access |= srp->smk_access1;
> sp->smk_access &= ~srp->smk_access2;
> break;
> }
>
>
>
>
> _______________________________________________
> SMACK-discuss mailing list
> SMACK-discuss(a)lists.01.org
>
https://lists.01.org/mailman/listinfo/smack-discuss