Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1181729 > unrolled thread

Re: kdbus: credential faking

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: kdbus: credential faking David Herrmann <dh.herrmann@gmail.com> - 2015-07-10 18:30 +0200
    Re: kdbus: credential faking Casey Schaufler <casey@schaufler-ca.com> - 2015-07-10 19:20 +0200
      Re: kdbus: credential faking Richard Weinberger <richard.weinberger@gmail.com> - 2015-07-11 13:40 +0200

#1181729 — Re: kdbus: credential faking

Hi

On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
[...]
>                There are so many ways uids are being (miss/ab)used
> on Linux systems these days that the idea of trusting a bus just
> because its non-root uid is listed in a table somewhere (or worse,
> coded in an API) is asking for exploits.

Please elaborate on these possible exploits. I'd also like to hear,
whether the same applies to the already used '/run/user/<uid>/bus',
which follows nearly the same model.

Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1181780

On 7/10/2015 9:26 AM, David Herrmann wrote:
> Hi
>
> On Fri, Jul 10, 2015 at 5:59 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> [...]
>>                There are so many ways uids are being (miss/ab)used
>> on Linux systems these days that the idea of trusting a bus just
>> because its non-root uid is listed in a table somewhere (or worse,
>> coded in an API) is asking for exploits.
> Please elaborate on these possible exploits. I'd also like to hear,
> whether the same applies to the already used '/run/user/<uid>/bus',
> which follows nearly the same model.

Sorry, I'm not the exploit generator guy. If I where, I would
point out that the application expecting the uid to identify
a person is going to behave incorrectly on the system that uses
the uid to identify an application. I never said that I liked
/run/user/<uid>/bus. Come to think of it, I never said I like
dbus, either.


>
> Thanks
> David
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1182138

On Fri, Jul 10, 2015 at 8:36 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> On some systems the uid is being used as an application identifier
> instead of a human identifier. The access controls are not designed
> for this. The POSIX capabilities aren't designed for this. If Fred
> creates a program that is setuid to fred and gets Barney to run it,
> you hold Fred accountable. If a malicious (or compromised) application
> identified by "fred" creates a setuid fred program and the "barney"
> application runs it, who do you hold accountable? It's a completely
> different mindset. Sure, you can wedge the one into the other, but
> it's not the intended use. Hence, misuse or abuse.

Actually that's an interesting thought.
The question is whether the /run/user/<uid>/bus security model works
also for "special" userland like Android.
To my knowledge on Android each application runs as different user.

If kdbus gets merged it would be nice to have to work with all kinds of userland
and not only Fedora.

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web