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

Groups > comp.arch.embedded > #26368

Re: exposing resource usage

Show all headers | View raw

On 4/13/2017 6:56 PM, Robert Wessel wrote:
> On Thu, 13 Apr 2017 18:22:05 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> Is there any potential downside to intentionally exposing
>> (to a task/process/job/etc.) its current resource commitments?
>> I.e., "You are currently holding X memory, Y CPU, Z ..."
>>
>> *If* the job is constrained to a particular set of quotas,
>> then knowing *what* it is using SHOULDN'T give it any
>> "exploitable" information, should it?
>>
>> [Open system; possibility for hostile actors]
>
> It depends on how paranoid you want to be.

Initially, I asked with an eye towards whether or not the
system's operational status could be compromised; if an exploit
could "crash" the system or render it effectively unusable.

E.g., if I don't allow a job to directly *query* its
resource quotas, it could still deduce them by empirically
increasing its resource usage and quantifying the result
(until the increases are denied).

    "Ah, OK.  I now know that I *can* use X, Y and Z!"

For example, in most systems, there is no *penalty* to
*attempting*:
     result = seteuid(0);
And, armed with this information, *later* using this capability
to nefarious ends.

OTOH, if this attempt caused the job to abend, it's harder
for a potential attacker to explore that capability without
tipping its hand that it is trying to do something that it
*shouldn't*!

> If some of the resources
> the process has access to may be influenced by other actors, that
> could expose a covert channel.

I'd have considered this a second-order problem.  However, see below...

> For example, if one of the bits of information was the number of real
> pages held by a task, then another task could make storage demands
> that could get some of the first processes' memory paged out (or

To be clear, I'm only talking about exposing YOUR resource usage
to *you*.  Of course, you could always communicate this (overtly
or covertly) to a co-conspirator.

But, you'd not be able to infer anything about other "non-cooperative"
jobs in the system.

The temptation is to dismiss this as an impractical issue.  *But*,
all vulnerabilities can be seen as falling in that sort of category!

Famous last words:  "What are the odds..."

<frown>

> discarded).  Similarly, the first process's CPU usage will be affected
> by other processes in the system.  Wiggle those back and forth, and
> you can do the equivalent of sending Morse code from one process to
> another.

In my initial read of this, I considered it unimportant:  if A and B want
to talk to each other, then let them open a channel to exchange information.

But, your point addresses a "false security" that could be exploited by
willing co-conspirators.

E.g., application A is relatively benign and is granted broad communication
privileges to The Outside World (e.g., a web browser).  OTOH, application B
handles sensitive information (that is protected by the OS from "local leaks")
and tightly constrained in its communication channels:  only having access to
The User (console) and "www.mybank.com" (because it -- and app A -- rely
on a service to provide the connections to The Outside World; A having
broad capabilities with this service but B *only* having a capability to
www.mybank.com!)

B is "sold" as a secure application because it "physically" can't disclose
the secrets that you've entrusted to it (bank account number, passphrase)
to any other parties!

However, A is published by "AAA Corporation" and B is similarly published by
"BBB Corporation (a wholly-owned subsidiary of AAA Corporation)".  So, the
"guarantees" that your OS provides are effectively useless (though they
would prevent application C from learning anything from A *or* B!)

Beyond that, if the system itself is widely disclosed, an attacker *might*
be able to infer the resource uses of other jobs by manipulating its
resource demands and noticing how those are met by the system in light of
the "well known" characteristics of the other aspects of The System
and its other apps.

[I.e., you can put units in a clean room and instrument them to your
heart's content without ever letting anyone/anything KNOW that you
are "quantifying" their behaviors in this way]

> OTOH, some of those can be exploited with help from the OS: just time
> how fast you're executing a loop - if another process also start
> running a CPU bound loop, you're rate should roughly halve.
>
> OTTH, I've always thought the whole covert channel thing was just a
> bit *too* paranoid.
>
> Unrelated to the above, I could see some of that knowledge being used
> to implement a DoS attack - tune your usage right up to the limit to
> maximize the possible impact on the system.

One would, presumably, ensure that the "reservations" placed on
resources for critical aspects of the system's performance would
ensure the system remains functional.  Though, how certain "optional"
aspects (apps) of the system would be impossible to guarantee a
certain level of performance.

OTOH, a savvy user would be able to see which apps are misbehaving
(with the help of an intelligent agent) -- either intentionally
*or* innocently -- and take steps to remove their deleterious
effects.

(sigh)  Thanks for bringing that to my attention!  It shoots to
shit my NEXT goal of providing a way for jobs to make themselves
aware of what other things are happening on the host  :<

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-13 18:22 -0700
  Re: exposing resource usage Robert Wessel <robertwessel2@yahoo.com> - 2017-04-13 20:56 -0500
    Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-13 22:26 -0700
    Re: exposing resource usage upsidedown@downunder.com - 2017-04-14 10:24 +0300
      Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 00:53 -0700
        Re: exposing resource usage upsidedown@downunder.com - 2017-04-14 12:53 +0300
          Re: exposing resource usage upsidedown@downunder.com - 2017-04-14 15:33 +0300
            Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 10:22 -0700
              Re: exposing resource usage upsidedown@downunder.com - 2017-04-17 20:24 +0300
                Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-17 12:13 -0700
            Re: exposing resource usage Dimiter_Popoff <dp@tgi-sci.com> - 2017-04-14 21:26 +0300
              Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 12:45 -0700
                Re: exposing resource usage Dimiter_Popoff <dp@tgi-sci.com> - 2017-04-15 00:27 +0300
                Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 20:45 -0700
          Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 10:11 -0700
  Re: exposing resource usage Tim Wescott <seemywebsite@myfooter.really> - 2017-04-14 12:54 -0500
    Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 11:44 -0700

csiph-web