Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 2:24 PM, Josh Boyer  wrote:
>
> Confining things through xattr labels on inodes.  ;)  FWIW, despite
> warnings to the contrary, the test system I have does boot just fine
> with SELinux in Enforcing mode.  It is likely the least scientific and
> useful scenario though, as it is just a dumb headless NUC box that all
> I do is test kernels on.  I won't even pretend that my mention here is
> anything more than an anecdote along the lines of "cool story, bro."

It's too bad that there isn't a well-supported way to lock down /proc
other than setting up inode labels and adding MAC policy.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Tue, Sep 1, 2015 at 4:11 PM, Andy Lutomirski  wrote:
> On Tue, Sep 1, 2015 at 12:54 PM, Josh Boyer  wrote:
>> On Tue, Sep 1, 2015 at 3:35 PM, Andy Lutomirski  wrote:
>>> No one in user namespace land has considered it acceptable for an old
>>> userspace that's running a new kernel with user namespaces turned on
>>> to have security problems as a result of user namespaces.  It's
>>> happened, but it's considered a problem to be fixed with high
>>> priority.  I'd be reassured if kdbus took a similar stance.
>>
>> And again, I'm not sure why you think the kdbus developers aren't?
>> You haven't found any security holes.  They haven't submitted a pull
>> request for 4.3.  As far as I can tell, things are still being worked
>> on and developed as expected.  I personally really appreciate your
>> diligence on the security aspects of kdbus.  Frankly, I hope you _do_
>> find security holes so that they can be fixed before it is merged.
>> But I've not seen anything that would indicate to me the kdbus
>> developers would ignore such an issue if you found one.
>>
>
> David said:
>
> If you use LSMs, we clearly advise you to wait for kdbus to gain LSM
> support. We explicitly support legacy dbus1-compat for exactly such
> reasons.
>
> If he means that I should wait for kdbus to gain LSM support and that
> kdbus won't go upstream until that happens, then that's a little bit
> better.  But there's still an issue that probably can't be addressed

FWIW, that's how I interpreted it.  Mostly because I haven't seen a
pull for 4.3 yet.

> purely in the kernel: unless some more magic that I'm not aware of in
> the existing userspace SELinux tooling (and all the other LSMs), then
> existing LSM policies will be insecure even on new kernels.  Maybe the
> LSM people consider this to be okay, but that would surprise me a
> little bit.  Or maybe kdbus with LSM hooks defaults to rejecting all

Isn't that a bit chicken and egg though?  I mean, we can coordinate
between the SELinux policy people to get it lined up as best as
possible.  Though when it comes to SELinux policy, the kernel rolls
out new features and userspace typically lags behind a bit.

I have no experience with other LSMs.

> metadata protected kdbus_proc_permission if the loaded policy doesn't
> explicitly support the new hooks.  I really don't know.

That's a possibility.  I also don't know.  I'd have to go look at the
proposed LSM patches again and I haven't see a revision of those in a
while.

> For all I know, this is a security hole as is -- it depends rather
> strongly on what people are doing with SELinux.

Confining things through xattr labels on inodes.  ;)  FWIW, despite
warnings to the contrary, the test system I have does boot just fine
with SELinux in Enforcing mode.  It is likely the least scientific and
useful scenario though, as it is just a dumb headless NUC box that all
I do is test kernels on.  I won't even pretend that my mention here is
anything more than an anecdote along the lines of "cool story, bro."

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 12:54 PM, Josh Boyer  wrote:
> On Tue, Sep 1, 2015 at 3:35 PM, Andy Lutomirski  wrote:
>> No one in user namespace land has considered it acceptable for an old
>> userspace that's running a new kernel with user namespaces turned on
>> to have security problems as a result of user namespaces.  It's
>> happened, but it's considered a problem to be fixed with high
>> priority.  I'd be reassured if kdbus took a similar stance.
>
> And again, I'm not sure why you think the kdbus developers aren't?
> You haven't found any security holes.  They haven't submitted a pull
> request for 4.3.  As far as I can tell, things are still being worked
> on and developed as expected.  I personally really appreciate your
> diligence on the security aspects of kdbus.  Frankly, I hope you _do_
> find security holes so that they can be fixed before it is merged.
> But I've not seen anything that would indicate to me the kdbus
> developers would ignore such an issue if you found one.
>

David said:

If you use LSMs, we clearly advise you to wait for kdbus to gain LSM
support. We explicitly support legacy dbus1-compat for exactly such
reasons.

If he means that I should wait for kdbus to gain LSM support and that
kdbus won't go upstream until that happens, then that's a little bit
better.  But there's still an issue that probably can't be addressed
purely in the kernel: unless some more magic that I'm not aware of in
the existing userspace SELinux tooling (and all the other LSMs), then
existing LSM policies will be insecure even on new kernels.  Maybe the
LSM people consider this to be okay, but that would surprise me a
little bit.  Or maybe kdbus with LSM hooks defaults to rejecting all
metadata protected kdbus_proc_permission if the loaded policy doesn't
explicitly support the new hooks.  I really don't know.

For all I know, this is a security hole as is -- it depends rather
strongly on what people are doing with SELinux.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Tue, Sep 1, 2015 at 3:35 PM, Andy Lutomirski  wrote:
> On Tue, Sep 1, 2015 at 12:04 PM, Josh Boyer  wrote:
>> So if someone wants to rebuild a kernel that contains the kdbus driver
>> and jump through the hoops you describe, then yes they might very well
>> run into problems you suggest might be present.  However, they will
>> also not be running Fedora 23 at that point.  I wish such users well
>> and thank them for their upstream testing efforts.
>>
>
> This does highlight a difference in configurations that the upstream
> kernel configures supported versus what Fedora considers supported.
> From Fedora's POV (correct me if I'm wrong), if you boot with a kernel
> with an unsupported configuration, it's unsupported.  From the
> upstream kernel's POV, if you flip on new features and boot an old
> distro, it's supposed to work with *very* few exceptions.

Well, mostly.  We've certainly turned on configuration options in the
Fedora kernel, reported problems with them, and been told by upstream
"why would you enable that?  It's not ready/relevant for distro use."
So in theory I agree with you, but not everyone follows those rules it
seems.

>> To be honest, I'm not sure what "process" you're talking about.
>> Kernel development is kind of rife with examples of new features
>> having security issues and it taking time to sort them out.  I don't
>> mean to cast aspersions, but user namespaces has had numerous CVEs
>> since it's inclusion.  I don't think anyone here has ever accused its
>> development of not following some kind of process.  And distros took
>> some time before enabling that feature, which is what I expect to
>> happen with kdbus should it ever be merged.  That certainly isn't an
>> argument for allowing _known_ security issues into the kernel, but as
>> you said, you haven't found a security hole as of yet.
>
> No one in user namespace land has considered it acceptable for an old
> userspace that's running a new kernel with user namespaces turned on
> to have security problems as a result of user namespaces.  It's
> happened, but it's considered a problem to be fixed with high
> priority.  I'd be reassured if kdbus took a similar stance.

And again, I'm not sure why you think the kdbus developers aren't?
You haven't found any security holes.  They haven't submitted a pull
request for 4.3.  As far as I can tell, things are still being worked
on and developed as expected.  I personally really appreciate your
diligence on the security aspects of kdbus.  Frankly, I hope you _do_
find security holes so that they can be fixed before it is merged.
But I've not seen anything that would indicate to me the kdbus
developers would ignore such an issue if you found one.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 12:04 PM, Josh Boyer  wrote:
> On Tue, Sep 1, 2015 at 2:31 PM, Andy Lutomirski  wrote:
>> On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer  
>> wrote:
>>> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  
>>> wrote:
 On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  
 wrote:
> Hi
>
> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  
> wrote:
>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
>> wrote:
>>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
>>> wrote:
 I haven't checked the context in which it's used, but in order for
 kdbus_proc_permission to do what it claims to do, it appears to be
 missing calls to security_inode_permission and
 security_file_permission.
>>>
>>> Both are expected to be added by lsm patches (both hooks you mentioned
>>> are empty if no lsm is selected).
>>
>> Will that mean that existing MAC policies stop being fully enforced
>> (in effect) if kdbus is installed?
>
> It means kdbus messages carry information about the sender, which LSMs
> might prevent you to read via /proc. Just like you can send dbus
> messages to a peer, which LSM-enhanced dbus-daemon might not allow.

 It's a security-sensitive function that doesn't do what the name and
 description suggest.  Whether that's an active problem or not is
 unknown, but it's certainly a maintainability problem.

> If
> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
> support. We explicitly support legacy dbus1-compat for exactly such
> reasons.

 This is not an acceptable attitude for security.

 There are so many things wrong with your statement that I'll limit
 myself to one of them: Fedora 23/Rawhide, which is the *reference*
 platform, uses SELinux.
>>>
>>> Clarification: Fedora Rawhide only.  The kdbus code is not included in
>>> the F23 kernel.
>>>
>>> Your point otherwise stands.  I just don't want Phoronix or someone
>>> else getting confused and thinking Fedora 23 will ship with kdbus.  It
>>> will not.
>>
>> But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
>> Granted, systemd is build with --disable-kdbus, but if it's a new
>> enough version, then I think that means that the code is still there.
>>
>> To be clear, I don't claim to have found a specific security hole, but
>> in the event that running Fedora 23 with a kdbus-supporting kernel and
>> booting with kdbus=1 [1] introduces security problems, then we have a
>> problem. (This isn't nearly as bad as it would be if we had problems
>> just by upgrading the kernel.)  And there is certainly something wrong
>> with the process if the kdbus team thinks it's okay that enabling
>> kdbus can break existing security policy.
>
> You seem to have interpreted my email as argumentation.  I don't want
> to argue.  I simply want to point out that Fedora 23 will not ship
> with kdbus in the kernel.  Therefore the Fedora 23 release, for its
> entire supported timeframe, will not utilize kdbus.

I don't want to argue either :)

>
> So if someone wants to rebuild a kernel that contains the kdbus driver
> and jump through the hoops you describe, then yes they might very well
> run into problems you suggest might be present.  However, they will
> also not be running Fedora 23 at that point.  I wish such users well
> and thank them for their upstream testing efforts.
>

This does highlight a difference in configurations that the upstream
kernel configures supported versus what Fedora considers supported.
>From Fedora's POV (correct me if I'm wrong), if you boot with a kernel
with an unsupported configuration, it's unsupported.  From the
upstream kernel's POV, if you flip on new features and boot an old
distro, it's supposed to work with *very* few exceptions.

> To be honest, I'm not sure what "process" you're talking about.
> Kernel development is kind of rife with examples of new features
> having security issues and it taking time to sort them out.  I don't
> mean to cast aspersions, but user namespaces has had numerous CVEs
> since it's inclusion.  I don't think anyone here has ever accused its
> development of not following some kind of process.  And distros took
> some time before enabling that feature, which is what I expect to
> happen with kdbus should it ever be merged.  That certainly isn't an
> argument for allowing _known_ security issues into the kernel, but as
> you said, you haven't found a security hole as of yet.

No one in user namespace land has considered it acceptable for an old
userspace that's running a new kernel with user namespaces turned on
to have security problems as a result of user namespaces.  It's
happened, but it's considered a problem to be fixed with high
priority.  I'd be reassured if kdbus took a similar stance.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a 

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Tue, Sep 1, 2015 at 2:31 PM, Andy Lutomirski  wrote:
> On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer  wrote:
>> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  wrote:
>>> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  
>>> wrote:
 Hi

 On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  
 wrote:
> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
> wrote:
>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
>> wrote:
>>> I haven't checked the context in which it's used, but in order for
>>> kdbus_proc_permission to do what it claims to do, it appears to be
>>> missing calls to security_inode_permission and
>>> security_file_permission.
>>
>> Both are expected to be added by lsm patches (both hooks you mentioned
>> are empty if no lsm is selected).
>
> Will that mean that existing MAC policies stop being fully enforced
> (in effect) if kdbus is installed?

 It means kdbus messages carry information about the sender, which LSMs
 might prevent you to read via /proc. Just like you can send dbus
 messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>>>
>>> It's a security-sensitive function that doesn't do what the name and
>>> description suggest.  Whether that's an active problem or not is
>>> unknown, but it's certainly a maintainability problem.
>>>
 If
 you use LSMs, we clearly advise you to wait for kdbus to gain LSM
 support. We explicitly support legacy dbus1-compat for exactly such
 reasons.
>>>
>>> This is not an acceptable attitude for security.
>>>
>>> There are so many things wrong with your statement that I'll limit
>>> myself to one of them: Fedora 23/Rawhide, which is the *reference*
>>> platform, uses SELinux.
>>
>> Clarification: Fedora Rawhide only.  The kdbus code is not included in
>> the F23 kernel.
>>
>> Your point otherwise stands.  I just don't want Phoronix or someone
>> else getting confused and thinking Fedora 23 will ship with kdbus.  It
>> will not.
>
> But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
> Granted, systemd is build with --disable-kdbus, but if it's a new
> enough version, then I think that means that the code is still there.
>
> To be clear, I don't claim to have found a specific security hole, but
> in the event that running Fedora 23 with a kdbus-supporting kernel and
> booting with kdbus=1 [1] introduces security problems, then we have a
> problem. (This isn't nearly as bad as it would be if we had problems
> just by upgrading the kernel.)  And there is certainly something wrong
> with the process if the kdbus team thinks it's okay that enabling
> kdbus can break existing security policy.

You seem to have interpreted my email as argumentation.  I don't want
to argue.  I simply want to point out that Fedora 23 will not ship
with kdbus in the kernel.  Therefore the Fedora 23 release, for its
entire supported timeframe, will not utilize kdbus.

So if someone wants to rebuild a kernel that contains the kdbus driver
and jump through the hoops you describe, then yes they might very well
run into problems you suggest might be present.  However, they will
also not be running Fedora 23 at that point.  I wish such users well
and thank them for their upstream testing efforts.

To be honest, I'm not sure what "process" you're talking about.
Kernel development is kind of rife with examples of new features
having security issues and it taking time to sort them out.  I don't
mean to cast aspersions, but user namespaces has had numerous CVEs
since it's inclusion.  I don't think anyone here has ever accused its
development of not following some kind of process.  And distros took
some time before enabling that feature, which is what I expect to
happen with kdbus should it ever be merged.  That certainly isn't an
argument for allowing _known_ security issues into the kernel, but as
you said, you haven't found a security hole as of yet.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer  wrote:
> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  wrote:
>> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  
>> wrote:
>>> Hi
>>>
>>> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  
>>> wrote:
 On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
 wrote:
> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
> wrote:
>> I haven't checked the context in which it's used, but in order for
>> kdbus_proc_permission to do what it claims to do, it appears to be
>> missing calls to security_inode_permission and
>> security_file_permission.
>
> Both are expected to be added by lsm patches (both hooks you mentioned
> are empty if no lsm is selected).

 Will that mean that existing MAC policies stop being fully enforced
 (in effect) if kdbus is installed?
>>>
>>> It means kdbus messages carry information about the sender, which LSMs
>>> might prevent you to read via /proc. Just like you can send dbus
>>> messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>>
>> It's a security-sensitive function that doesn't do what the name and
>> description suggest.  Whether that's an active problem or not is
>> unknown, but it's certainly a maintainability problem.
>>
>>> If
>>> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
>>> support. We explicitly support legacy dbus1-compat for exactly such
>>> reasons.
>>
>> This is not an acceptable attitude for security.
>>
>> There are so many things wrong with your statement that I'll limit
>> myself to one of them: Fedora 23/Rawhide, which is the *reference*
>> platform, uses SELinux.
>
> Clarification: Fedora Rawhide only.  The kdbus code is not included in
> the F23 kernel.
>
> Your point otherwise stands.  I just don't want Phoronix or someone
> else getting confused and thinking Fedora 23 will ship with kdbus.  It
> will not.

But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
Granted, systemd is build with --disable-kdbus, but if it's a new
enough version, then I think that means that the code is still there.

To be clear, I don't claim to have found a specific security hole, but
in the event that running Fedora 23 with a kdbus-supporting kernel and
booting with kdbus=1 [1] introduces security problems, then we have a
problem. (This isn't nearly as bad as it would be if we had problems
just by upgrading the kernel.)  And there is certainly something wrong
with the process if the kdbus team thinks it's okay that enabling
kdbus can break existing security policy.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  wrote:
> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  wrote:
>> Hi
>>
>> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  wrote:
>>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
>>> wrote:
 On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
 wrote:
> I haven't checked the context in which it's used, but in order for
> kdbus_proc_permission to do what it claims to do, it appears to be
> missing calls to security_inode_permission and
> security_file_permission.

 Both are expected to be added by lsm patches (both hooks you mentioned
 are empty if no lsm is selected).
>>>
>>> Will that mean that existing MAC policies stop being fully enforced
>>> (in effect) if kdbus is installed?
>>
>> It means kdbus messages carry information about the sender, which LSMs
>> might prevent you to read via /proc. Just like you can send dbus
>> messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>
> It's a security-sensitive function that doesn't do what the name and
> description suggest.  Whether that's an active problem or not is
> unknown, but it's certainly a maintainability problem.
>
>> If
>> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
>> support. We explicitly support legacy dbus1-compat for exactly such
>> reasons.
>
> This is not an acceptable attitude for security.
>
> There are so many things wrong with your statement that I'll limit
> myself to one of them: Fedora 23/Rawhide, which is the *reference*
> platform, uses SELinux.

Clarification: Fedora Rawhide only.  The kdbus code is not included in
the F23 kernel.

Your point otherwise stands.  I just don't want Phoronix or someone
else getting confused and thinking Fedora 23 will ship with kdbus.  It
will not.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Tue, Sep 1, 2015 at 3:35 PM, Andy Lutomirski  wrote:
> On Tue, Sep 1, 2015 at 12:04 PM, Josh Boyer  wrote:
>> So if someone wants to rebuild a kernel that contains the kdbus driver
>> and jump through the hoops you describe, then yes they might very well
>> run into problems you suggest might be present.  However, they will
>> also not be running Fedora 23 at that point.  I wish such users well
>> and thank them for their upstream testing efforts.
>>
>
> This does highlight a difference in configurations that the upstream
> kernel configures supported versus what Fedora considers supported.
> From Fedora's POV (correct me if I'm wrong), if you boot with a kernel
> with an unsupported configuration, it's unsupported.  From the
> upstream kernel's POV, if you flip on new features and boot an old
> distro, it's supposed to work with *very* few exceptions.

Well, mostly.  We've certainly turned on configuration options in the
Fedora kernel, reported problems with them, and been told by upstream
"why would you enable that?  It's not ready/relevant for distro use."
So in theory I agree with you, but not everyone follows those rules it
seems.

>> To be honest, I'm not sure what "process" you're talking about.
>> Kernel development is kind of rife with examples of new features
>> having security issues and it taking time to sort them out.  I don't
>> mean to cast aspersions, but user namespaces has had numerous CVEs
>> since it's inclusion.  I don't think anyone here has ever accused its
>> development of not following some kind of process.  And distros took
>> some time before enabling that feature, which is what I expect to
>> happen with kdbus should it ever be merged.  That certainly isn't an
>> argument for allowing _known_ security issues into the kernel, but as
>> you said, you haven't found a security hole as of yet.
>
> No one in user namespace land has considered it acceptable for an old
> userspace that's running a new kernel with user namespaces turned on
> to have security problems as a result of user namespaces.  It's
> happened, but it's considered a problem to be fixed with high
> priority.  I'd be reassured if kdbus took a similar stance.

And again, I'm not sure why you think the kdbus developers aren't?
You haven't found any security holes.  They haven't submitted a pull
request for 4.3.  As far as I can tell, things are still being worked
on and developed as expected.  I personally really appreciate your
diligence on the security aspects of kdbus.  Frankly, I hope you _do_
find security holes so that they can be fixed before it is merged.
But I've not seen anything that would indicate to me the kdbus
developers would ignore such an issue if you found one.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  wrote:
> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  wrote:
>> Hi
>>
>> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  wrote:
>>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
>>> wrote:
 On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
 wrote:
> I haven't checked the context in which it's used, but in order for
> kdbus_proc_permission to do what it claims to do, it appears to be
> missing calls to security_inode_permission and
> security_file_permission.

 Both are expected to be added by lsm patches (both hooks you mentioned
 are empty if no lsm is selected).
>>>
>>> Will that mean that existing MAC policies stop being fully enforced
>>> (in effect) if kdbus is installed?
>>
>> It means kdbus messages carry information about the sender, which LSMs
>> might prevent you to read via /proc. Just like you can send dbus
>> messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>
> It's a security-sensitive function that doesn't do what the name and
> description suggest.  Whether that's an active problem or not is
> unknown, but it's certainly a maintainability problem.
>
>> If
>> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
>> support. We explicitly support legacy dbus1-compat for exactly such
>> reasons.
>
> This is not an acceptable attitude for security.
>
> There are so many things wrong with your statement that I'll limit
> myself to one of them: Fedora 23/Rawhide, which is the *reference*
> platform, uses SELinux.

Clarification: Fedora Rawhide only.  The kdbus code is not included in
the F23 kernel.

Your point otherwise stands.  I just don't want Phoronix or someone
else getting confused and thinking Fedora 23 will ship with kdbus.  It
will not.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer  wrote:
> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  wrote:
>> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  
>> wrote:
>>> Hi
>>>
>>> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  
>>> wrote:
 On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
 wrote:
> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
> wrote:
>> I haven't checked the context in which it's used, but in order for
>> kdbus_proc_permission to do what it claims to do, it appears to be
>> missing calls to security_inode_permission and
>> security_file_permission.
>
> Both are expected to be added by lsm patches (both hooks you mentioned
> are empty if no lsm is selected).

 Will that mean that existing MAC policies stop being fully enforced
 (in effect) if kdbus is installed?
>>>
>>> It means kdbus messages carry information about the sender, which LSMs
>>> might prevent you to read via /proc. Just like you can send dbus
>>> messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>>
>> It's a security-sensitive function that doesn't do what the name and
>> description suggest.  Whether that's an active problem or not is
>> unknown, but it's certainly a maintainability problem.
>>
>>> If
>>> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
>>> support. We explicitly support legacy dbus1-compat for exactly such
>>> reasons.
>>
>> This is not an acceptable attitude for security.
>>
>> There are so many things wrong with your statement that I'll limit
>> myself to one of them: Fedora 23/Rawhide, which is the *reference*
>> platform, uses SELinux.
>
> Clarification: Fedora Rawhide only.  The kdbus code is not included in
> the F23 kernel.
>
> Your point otherwise stands.  I just don't want Phoronix or someone
> else getting confused and thinking Fedora 23 will ship with kdbus.  It
> will not.

But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
Granted, systemd is build with --disable-kdbus, but if it's a new
enough version, then I think that means that the code is still there.

To be clear, I don't claim to have found a specific security hole, but
in the event that running Fedora 23 with a kdbus-supporting kernel and
booting with kdbus=1 [1] introduces security problems, then we have a
problem. (This isn't nearly as bad as it would be if we had problems
just by upgrading the kernel.)  And there is certainly something wrong
with the process if the kdbus team thinks it's okay that enabling
kdbus can break existing security policy.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Tue, Sep 1, 2015 at 2:31 PM, Andy Lutomirski  wrote:
> On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer  wrote:
>> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  wrote:
>>> On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  
>>> wrote:
 Hi

 On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  
 wrote:
> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
> wrote:
>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
>> wrote:
>>> I haven't checked the context in which it's used, but in order for
>>> kdbus_proc_permission to do what it claims to do, it appears to be
>>> missing calls to security_inode_permission and
>>> security_file_permission.
>>
>> Both are expected to be added by lsm patches (both hooks you mentioned
>> are empty if no lsm is selected).
>
> Will that mean that existing MAC policies stop being fully enforced
> (in effect) if kdbus is installed?

 It means kdbus messages carry information about the sender, which LSMs
 might prevent you to read via /proc. Just like you can send dbus
 messages to a peer, which LSM-enhanced dbus-daemon might not allow.
>>>
>>> It's a security-sensitive function that doesn't do what the name and
>>> description suggest.  Whether that's an active problem or not is
>>> unknown, but it's certainly a maintainability problem.
>>>
 If
 you use LSMs, we clearly advise you to wait for kdbus to gain LSM
 support. We explicitly support legacy dbus1-compat for exactly such
 reasons.
>>>
>>> This is not an acceptable attitude for security.
>>>
>>> There are so many things wrong with your statement that I'll limit
>>> myself to one of them: Fedora 23/Rawhide, which is the *reference*
>>> platform, uses SELinux.
>>
>> Clarification: Fedora Rawhide only.  The kdbus code is not included in
>> the F23 kernel.
>>
>> Your point otherwise stands.  I just don't want Phoronix or someone
>> else getting confused and thinking Fedora 23 will ship with kdbus.  It
>> will not.
>
> But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
> Granted, systemd is build with --disable-kdbus, but if it's a new
> enough version, then I think that means that the code is still there.
>
> To be clear, I don't claim to have found a specific security hole, but
> in the event that running Fedora 23 with a kdbus-supporting kernel and
> booting with kdbus=1 [1] introduces security problems, then we have a
> problem. (This isn't nearly as bad as it would be if we had problems
> just by upgrading the kernel.)  And there is certainly something wrong
> with the process if the kdbus team thinks it's okay that enabling
> kdbus can break existing security policy.

You seem to have interpreted my email as argumentation.  I don't want
to argue.  I simply want to point out that Fedora 23 will not ship
with kdbus in the kernel.  Therefore the Fedora 23 release, for its
entire supported timeframe, will not utilize kdbus.

So if someone wants to rebuild a kernel that contains the kdbus driver
and jump through the hoops you describe, then yes they might very well
run into problems you suggest might be present.  However, they will
also not be running Fedora 23 at that point.  I wish such users well
and thank them for their upstream testing efforts.

To be honest, I'm not sure what "process" you're talking about.
Kernel development is kind of rife with examples of new features
having security issues and it taking time to sort them out.  I don't
mean to cast aspersions, but user namespaces has had numerous CVEs
since it's inclusion.  I don't think anyone here has ever accused its
development of not following some kind of process.  And distros took
some time before enabling that feature, which is what I expect to
happen with kdbus should it ever be merged.  That certainly isn't an
argument for allowing _known_ security issues into the kernel, but as
you said, you haven't found a security hole as of yet.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 12:04 PM, Josh Boyer  wrote:
> On Tue, Sep 1, 2015 at 2:31 PM, Andy Lutomirski  wrote:
>> On Tue, Sep 1, 2015 at 10:13 AM, Josh Boyer  
>> wrote:
>>> On Mon, Aug 31, 2015 at 3:09 PM, Andy Lutomirski  
>>> wrote:
 On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  
 wrote:
> Hi
>
> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  
> wrote:
>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
>> wrote:
>>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
>>> wrote:
 I haven't checked the context in which it's used, but in order for
 kdbus_proc_permission to do what it claims to do, it appears to be
 missing calls to security_inode_permission and
 security_file_permission.
>>>
>>> Both are expected to be added by lsm patches (both hooks you mentioned
>>> are empty if no lsm is selected).
>>
>> Will that mean that existing MAC policies stop being fully enforced
>> (in effect) if kdbus is installed?
>
> It means kdbus messages carry information about the sender, which LSMs
> might prevent you to read via /proc. Just like you can send dbus
> messages to a peer, which LSM-enhanced dbus-daemon might not allow.

 It's a security-sensitive function that doesn't do what the name and
 description suggest.  Whether that's an active problem or not is
 unknown, but it's certainly a maintainability problem.

> If
> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
> support. We explicitly support legacy dbus1-compat for exactly such
> reasons.

 This is not an acceptable attitude for security.

 There are so many things wrong with your statement that I'll limit
 myself to one of them: Fedora 23/Rawhide, which is the *reference*
 platform, uses SELinux.
>>>
>>> Clarification: Fedora Rawhide only.  The kdbus code is not included in
>>> the F23 kernel.
>>>
>>> Your point otherwise stands.  I just don't want Phoronix or someone
>>> else getting confused and thinking Fedora 23 will ship with kdbus.  It
>>> will not.
>>
>> But a bunch of kdbus code does appear in Fedora 23 userspace, I think.
>> Granted, systemd is build with --disable-kdbus, but if it's a new
>> enough version, then I think that means that the code is still there.
>>
>> To be clear, I don't claim to have found a specific security hole, but
>> in the event that running Fedora 23 with a kdbus-supporting kernel and
>> booting with kdbus=1 [1] introduces security problems, then we have a
>> problem. (This isn't nearly as bad as it would be if we had problems
>> just by upgrading the kernel.)  And there is certainly something wrong
>> with the process if the kdbus team thinks it's okay that enabling
>> kdbus can break existing security policy.
>
> You seem to have interpreted my email as argumentation.  I don't want
> to argue.  I simply want to point out that Fedora 23 will not ship
> with kdbus in the kernel.  Therefore the Fedora 23 release, for its
> entire supported timeframe, will not utilize kdbus.

I don't want to argue either :)

>
> So if someone wants to rebuild a kernel that contains the kdbus driver
> and jump through the hoops you describe, then yes they might very well
> run into problems you suggest might be present.  However, they will
> also not be running Fedora 23 at that point.  I wish such users well
> and thank them for their upstream testing efforts.
>

This does highlight a difference in configurations that the upstream
kernel configures supported versus what Fedora considers supported.
>From Fedora's POV (correct me if I'm wrong), if you boot with a kernel
with an unsupported configuration, it's unsupported.  From the
upstream kernel's POV, if you flip on new features and boot an old
distro, it's supposed to work with *very* few exceptions.

> To be honest, I'm not sure what "process" you're talking about.
> Kernel development is kind of rife with examples of new features
> having security issues and it taking time to sort them out.  I don't
> mean to cast aspersions, but user namespaces has had numerous CVEs
> since it's inclusion.  I don't think anyone here has ever accused its
> development of not following some kind of process.  And distros took
> some time before enabling that feature, which is what I expect to
> happen with kdbus should it ever be merged.  That certainly isn't an
> argument for allowing _known_ security issues into the kernel, but as
> you said, you haven't found a security hole as of yet.

No one in user namespace land has considered it acceptable for an old
userspace that's running a new kernel with user namespaces turned on
to have security problems as a result of user namespaces.  It's
happened, but it's considered a 

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 12:54 PM, Josh Boyer  wrote:
> On Tue, Sep 1, 2015 at 3:35 PM, Andy Lutomirski  wrote:
>> No one in user namespace land has considered it acceptable for an old
>> userspace that's running a new kernel with user namespaces turned on
>> to have security problems as a result of user namespaces.  It's
>> happened, but it's considered a problem to be fixed with high
>> priority.  I'd be reassured if kdbus took a similar stance.
>
> And again, I'm not sure why you think the kdbus developers aren't?
> You haven't found any security holes.  They haven't submitted a pull
> request for 4.3.  As far as I can tell, things are still being worked
> on and developed as expected.  I personally really appreciate your
> diligence on the security aspects of kdbus.  Frankly, I hope you _do_
> find security holes so that they can be fixed before it is merged.
> But I've not seen anything that would indicate to me the kdbus
> developers would ignore such an issue if you found one.
>

David said:

If you use LSMs, we clearly advise you to wait for kdbus to gain LSM
support. We explicitly support legacy dbus1-compat for exactly such
reasons.

If he means that I should wait for kdbus to gain LSM support and that
kdbus won't go upstream until that happens, then that's a little bit
better.  But there's still an issue that probably can't be addressed
purely in the kernel: unless some more magic that I'm not aware of in
the existing userspace SELinux tooling (and all the other LSMs), then
existing LSM policies will be insecure even on new kernels.  Maybe the
LSM people consider this to be okay, but that would surprise me a
little bit.  Or maybe kdbus with LSM hooks defaults to rejecting all
metadata protected kdbus_proc_permission if the loaded policy doesn't
explicitly support the new hooks.  I really don't know.

For all I know, this is a security hole as is -- it depends rather
strongly on what people are doing with SELinux.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Tue, Sep 1, 2015 at 2:24 PM, Josh Boyer  wrote:
>
> Confining things through xattr labels on inodes.  ;)  FWIW, despite
> warnings to the contrary, the test system I have does boot just fine
> with SELinux in Enforcing mode.  It is likely the least scientific and
> useful scenario though, as it is just a dumb headless NUC box that all
> I do is test kernels on.  I won't even pretend that my mention here is
> anything more than an anecdote along the lines of "cool story, bro."

It's too bad that there isn't a well-supported way to lock down /proc
other than setting up inode labels and adding MAC policy.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Josh Boyer]

On Tue, Sep 1, 2015 at 4:11 PM, Andy Lutomirski  wrote:
> On Tue, Sep 1, 2015 at 12:54 PM, Josh Boyer  wrote:
>> On Tue, Sep 1, 2015 at 3:35 PM, Andy Lutomirski  wrote:
>>> No one in user namespace land has considered it acceptable for an old
>>> userspace that's running a new kernel with user namespaces turned on
>>> to have security problems as a result of user namespaces.  It's
>>> happened, but it's considered a problem to be fixed with high
>>> priority.  I'd be reassured if kdbus took a similar stance.
>>
>> And again, I'm not sure why you think the kdbus developers aren't?
>> You haven't found any security holes.  They haven't submitted a pull
>> request for 4.3.  As far as I can tell, things are still being worked
>> on and developed as expected.  I personally really appreciate your
>> diligence on the security aspects of kdbus.  Frankly, I hope you _do_
>> find security holes so that they can be fixed before it is merged.
>> But I've not seen anything that would indicate to me the kdbus
>> developers would ignore such an issue if you found one.
>>
>
> David said:
>
> If you use LSMs, we clearly advise you to wait for kdbus to gain LSM
> support. We explicitly support legacy dbus1-compat for exactly such
> reasons.
>
> If he means that I should wait for kdbus to gain LSM support and that
> kdbus won't go upstream until that happens, then that's a little bit
> better.  But there's still an issue that probably can't be addressed

FWIW, that's how I interpreted it.  Mostly because I haven't seen a
pull for 4.3 yet.

> purely in the kernel: unless some more magic that I'm not aware of in
> the existing userspace SELinux tooling (and all the other LSMs), then
> existing LSM policies will be insecure even on new kernels.  Maybe the
> LSM people consider this to be okay, but that would surprise me a
> little bit.  Or maybe kdbus with LSM hooks defaults to rejecting all

Isn't that a bit chicken and egg though?  I mean, we can coordinate
between the SELinux policy people to get it lined up as best as
possible.  Though when it comes to SELinux policy, the kernel rolls
out new features and userspace typically lags behind a bit.

I have no experience with other LSMs.

> metadata protected kdbus_proc_permission if the loaded policy doesn't
> explicitly support the new hooks.  I really don't know.

That's a possibility.  I also don't know.  I'd have to go look at the
proposed LSM patches again and I haven't see a revision of those in a
while.

> For all I know, this is a security hole as is -- it depends rather
> strongly on what people are doing with SELinux.

Confining things through xattr labels on inodes.  ;)  FWIW, despite
warnings to the contrary, the test system I have does boot just fine
with SELinux in Enforcing mode.  It is likely the least scientific and
useful scenario though, as it is just a dumb headless NUC box that all
I do is test kernels on.  I won't even pretend that my mention here is
anything more than an anecdote along the lines of "cool story, bro."

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  wrote:
> Hi
>
> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  wrote:
>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
>> wrote:
>>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
>>> wrote:
 I haven't checked the context in which it's used, but in order for
 kdbus_proc_permission to do what it claims to do, it appears to be
 missing calls to security_inode_permission and
 security_file_permission.
>>>
>>> Both are expected to be added by lsm patches (both hooks you mentioned
>>> are empty if no lsm is selected).
>>
>> Will that mean that existing MAC policies stop being fully enforced
>> (in effect) if kdbus is installed?
>
> It means kdbus messages carry information about the sender, which LSMs
> might prevent you to read via /proc. Just like you can send dbus
> messages to a peer, which LSM-enhanced dbus-daemon might not allow.

It's a security-sensitive function that doesn't do what the name and
description suggest.  Whether that's an active problem or not is
unknown, but it's certainly a maintainability problem.

> If
> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
> support. We explicitly support legacy dbus1-compat for exactly such
> reasons.

This is not an acceptable attitude for security.

There are so many things wrong with your statement that I'll limit
myself to one of them: Fedora 23/Rawhide, which is the *reference*
platform, uses SELinux.

--Andy

>
> Thanks
> David



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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[David Herrmann]

Hi

On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  wrote:
> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  wrote:
>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  wrote:
>>> I haven't checked the context in which it's used, but in order for
>>> kdbus_proc_permission to do what it claims to do, it appears to be
>>> missing calls to security_inode_permission and
>>> security_file_permission.
>>
>> Both are expected to be added by lsm patches (both hooks you mentioned
>> are empty if no lsm is selected).
>
> Will that mean that existing MAC policies stop being fully enforced
> (in effect) if kdbus is installed?

It means kdbus messages carry information about the sender, which LSMs
might prevent you to read via /proc. Just like you can send dbus
messages to a peer, which LSM-enhanced dbus-daemon might not allow. If
you use LSMs, we clearly advise you to wait for kdbus to gain LSM
support. We explicitly support legacy dbus1-compat for exactly such
reasons.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  wrote:
> Hi
>
> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  wrote:
>> I spotted this:
>>
>> +/**
>> + * kdbus_proc_permission() - check /proc permissions on target pid
>> + * @pid_ns:namespace we operate in
>> + * @cred:  credentials of requestor
>> + * @target:target process
>> + *
>> + * This checks whether a process with credentials @cred can access 
>> information
>> + * of @target in the namespace @pid_ns. This tries to follow /proc 
>> permissions,
>> + * but is slightly more restrictive.
>> + *
>> + * Return: The /proc access level (KDBUS_META_PROC_*) is returned.
>> + */
>> +static unsigned int kdbus_proc_permission(const struct pid_namespace 
>> *pid_ns,
>> + const struct cred *cred,
>> + struct pid *target)
>>
>> That code ended up in a pull request, although AFAICT it was never in
>> any patch email sent to me or to any public mailing list.  I suspect
>> it was at least partially a response to one of my old reviews.
>
> Exactly. It's an attempt to model metadata access similar to /proc
> access (thus, access to kdbusfs implies access to procfs, but not vice
> versa (nor any implication on hidepid)).

I haven't looked at what calls this function, but I guess the model is
inaccurate and errs in the too-permissive direction.

Fedora actually labels inodes in /proc (ls -Zd /proc/???, for
example), but I don't know what it does with those labels.

>
>> I haven't checked the context in which it's used, but in order for
>> kdbus_proc_permission to do what it claims to do, it appears to be
>> missing calls to security_inode_permission and
>> security_file_permission.
>
> Both are expected to be added by lsm patches (both hooks you mentioned
> are empty if no lsm is selected).

Will that mean that existing MAC policies stop being fully enforced
(in effect) if kdbus is installed?

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  wrote:
> Hi
>
> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  wrote:
>> I spotted this:
>>
>> +/**
>> + * kdbus_proc_permission() - check /proc permissions on target pid
>> + * @pid_ns:namespace we operate in
>> + * @cred:  credentials of requestor
>> + * @target:target process
>> + *
>> + * This checks whether a process with credentials @cred can access 
>> information
>> + * of @target in the namespace @pid_ns. This tries to follow /proc 
>> permissions,
>> + * but is slightly more restrictive.
>> + *
>> + * Return: The /proc access level (KDBUS_META_PROC_*) is returned.
>> + */
>> +static unsigned int kdbus_proc_permission(const struct pid_namespace 
>> *pid_ns,
>> + const struct cred *cred,
>> + struct pid *target)
>>
>> That code ended up in a pull request, although AFAICT it was never in
>> any patch email sent to me or to any public mailing list.  I suspect
>> it was at least partially a response to one of my old reviews.
>
> Exactly. It's an attempt to model metadata access similar to /proc
> access (thus, access to kdbusfs implies access to procfs, but not vice
> versa (nor any implication on hidepid)).

I haven't looked at what calls this function, but I guess the model is
inaccurate and errs in the too-permissive direction.

Fedora actually labels inodes in /proc (ls -Zd /proc/???, for
example), but I don't know what it does with those labels.

>
>> I haven't checked the context in which it's used, but in order for
>> kdbus_proc_permission to do what it claims to do, it appears to be
>> missing calls to security_inode_permission and
>> security_file_permission.
>
> Both are expected to be added by lsm patches (both hooks you mentioned
> are empty if no lsm is selected).

Will that mean that existing MAC policies stop being fully enforced
(in effect) if kdbus is installed?

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[David Herrmann]

Hi

On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  wrote:
> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  wrote:
>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  wrote:
>>> I haven't checked the context in which it's used, but in order for
>>> kdbus_proc_permission to do what it claims to do, it appears to be
>>> missing calls to security_inode_permission and
>>> security_file_permission.
>>
>> Both are expected to be added by lsm patches (both hooks you mentioned
>> are empty if no lsm is selected).
>
> Will that mean that existing MAC policies stop being fully enforced
> (in effect) if kdbus is installed?

It means kdbus messages carry information about the sender, which LSMs
might prevent you to read via /proc. Just like you can send dbus
messages to a peer, which LSM-enhanced dbus-daemon might not allow. If
you use LSMs, we clearly advise you to wait for kdbus to gain LSM
support. We explicitly support legacy dbus1-compat for exactly such
reasons.

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

On Mon, Aug 31, 2015 at 9:22 AM, David Herrmann  wrote:
> Hi
>
> On Mon, Aug 31, 2015 at 5:37 PM, Andy Lutomirski  wrote:
>> On Mon, Aug 24, 2015 at 2:52 AM, David Herrmann  
>> wrote:
>>> On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  
>>> wrote:
 I haven't checked the context in which it's used, but in order for
 kdbus_proc_permission to do what it claims to do, it appears to be
 missing calls to security_inode_permission and
 security_file_permission.
>>>
>>> Both are expected to be added by lsm patches (both hooks you mentioned
>>> are empty if no lsm is selected).
>>
>> Will that mean that existing MAC policies stop being fully enforced
>> (in effect) if kdbus is installed?
>
> It means kdbus messages carry information about the sender, which LSMs
> might prevent you to read via /proc. Just like you can send dbus
> messages to a peer, which LSM-enhanced dbus-daemon might not allow.

It's a security-sensitive function that doesn't do what the name and
description suggest.  Whether that's an active problem or not is
unknown, but it's certainly a maintainability problem.

> If
> you use LSMs, we clearly advise you to wait for kdbus to gain LSM
> support. We explicitly support legacy dbus1-compat for exactly such
> reasons.

This is not an acceptable attitude for security.

There are so many things wrong with your statement that I'll limit
myself to one of them: Fedora 23/Rawhide, which is the *reference*
platform, uses SELinux.

--Andy

>
> Thanks
> David



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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[David Herrmann]

Hi

On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski  wrote:
> I spotted this:
>
> +/**
> + * kdbus_proc_permission() - check /proc permissions on target pid
> + * @pid_ns:namespace we operate in
> + * @cred:  credentials of requestor
> + * @target:target process
> + *
> + * This checks whether a process with credentials @cred can access 
> information
> + * of @target in the namespace @pid_ns. This tries to follow /proc 
> permissions,
> + * but is slightly more restrictive.
> + *
> + * Return: The /proc access level (KDBUS_META_PROC_*) is returned.
> + */
> +static unsigned int kdbus_proc_permission(const struct pid_namespace *pid_ns,
> + const struct cred *cred,
> + struct pid *target)
>
> That code ended up in a pull request, although AFAICT it was never in
> any patch email sent to me or to any public mailing list.  I suspect
> it was at least partially a response to one of my old reviews.

Exactly. It's an attempt to model metadata access similar to /proc
access (thus, access to kdbusfs implies access to procfs, but not vice
versa (nor any implication on hidepid)).

> I haven't checked the context in which it's used, but in order for
> kdbus_proc_permission to do what it claims to do, it appears to be
> missing calls to security_inode_permission and
> security_file_permission.

Both are expected to be added by lsm patches (both hooks you mentioned
are empty if no lsm is selected).

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

Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[David Herrmann]

Hi

On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski l...@amacapital.net wrote:
 I spotted this:

 +/**
 + * kdbus_proc_permission() - check /proc permissions on target pid
 + * @pid_ns:namespace we operate in
 + * @cred:  credentials of requestor
 + * @target:target process
 + *
 + * This checks whether a process with credentials @cred can access 
 information
 + * of @target in the namespace @pid_ns. This tries to follow /proc 
 permissions,
 + * but is slightly more restrictive.
 + *
 + * Return: The /proc access level (KDBUS_META_PROC_*) is returned.
 + */
 +static unsigned int kdbus_proc_permission(const struct pid_namespace *pid_ns,
 + const struct cred *cred,
 + struct pid *target)

 That code ended up in a pull request, although AFAICT it was never in
 any patch email sent to me or to any public mailing list.  I suspect
 it was at least partially a response to one of my old reviews.

Exactly. It's an attempt to model metadata access similar to /proc
access (thus, access to kdbusfs implies access to procfs, but not vice
versa (nor any implication on hidepid)).

 I haven't checked the context in which it's used, but in order for
 kdbus_proc_permission to do what it claims to do, it appears to be
 missing calls to security_inode_permission and
 security_file_permission.

Both are expected to be added by lsm patches (both hooks you mentioned
are empty if no lsm is selected).

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

kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

I spotted this:

+/**
+ * kdbus_proc_permission() - check /proc permissions on target pid
+ * @pid_ns:namespace we operate in
+ * @cred:  credentials of requestor
+ * @target:target process
+ *
+ * This checks whether a process with credentials @cred can access information
+ * of @target in the namespace @pid_ns. This tries to follow /proc permissions,
+ * but is slightly more restrictive.
+ *
+ * Return: The /proc access level (KDBUS_META_PROC_*) is returned.
+ */
+static unsigned int kdbus_proc_permission(const struct pid_namespace *pid_ns,
+ const struct cred *cred,
+ struct pid *target)

That code ended up in a pull request, although AFAICT it was never in
any patch email sent to me or to any public mailing list.  I suspect
it was at least partially a response to one of my old reviews.

I haven't checked the context in which it's used, but in order for
kdbus_proc_permission to do what it claims to do, it appears to be
missing calls to security_inode_permission and
security_file_permission.

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

kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg)

[Andy Lutomirski]

I spotted this:

+/**
+ * kdbus_proc_permission() - check /proc permissions on target pid
+ * @pid_ns:namespace we operate in
+ * @cred:  credentials of requestor
+ * @target:target process
+ *
+ * This checks whether a process with credentials @cred can access information
+ * of @target in the namespace @pid_ns. This tries to follow /proc permissions,
+ * but is slightly more restrictive.
+ *
+ * Return: The /proc access level (KDBUS_META_PROC_*) is returned.
+ */
+static unsigned int kdbus_proc_permission(const struct pid_namespace *pid_ns,
+ const struct cred *cred,
+ struct pid *target)

That code ended up in a pull request, although AFAICT it was never in
any patch email sent to me or to any public mailing list.  I suspect
it was at least partially a response to one of my old reviews.

I haven't checked the context in which it's used, but in order for
kdbus_proc_permission to do what it claims to do, it appears to be
missing calls to security_inode_permission and
security_file_permission.

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