autotest: Bring platform_ProcessPrivileges test up to date

autotest: Bring platform_ProcessPrivileges test up to date

Change-Id: I1adf121dbdb021654a056d6828f4100d70804c0a

BUG=5618
TEST=Ran on dev and test farm machines

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=b4128fc

[kmixter1, 2010-09-24 17:15:43]

This test has been failing because it's out of date.  Brought it up to date. 
I'm not sure what Jim's plans are with platform_ProcessPrivilegesComprehensive -
why it's a separate test and why it's not in a suite, but since this one is in
the nightly suite, fixing it.

[petkov, 2010-09-24 17:26:40]

LGTM

[jimhebert, 2010-09-24 18:01:24]

platform_ProcessPrivileges is an older test (not authored by me) that spot
checks just a few things (< 12).  For example, any processes it's not
specifically configured to look for, which exist on the system, don't cause
a test failure.  This makes it a pretty non-brittle smoke test and is good
for build verification or similar.  I don't have anything to do with this
test, but am glad to see it getting updated, thanks for doing that.

I got a request to produce a test that accounts for all (> 100) process
privileges on the system.  We looked at the existing test and it didn't meet
this need. E.g. if there's a new root-owned process that the test has never
seen before, we want to go investigate if we're slipping backwards in terms
of system security hardening.  That's
platform_ProcessPrivilegesComprehensive.  This type of test is extremely
brittle, 99% of the time when something like this makes noise, a human
reviews it and decides to update the test-expectations.  That's just the
nature of what we've asked of it.

That test has not been added to a suite yet. Due to the brittle nature with
a repetitive review-update-baseline-try-again-tomorrow loop, it may not be a
great candidate for sticking into the nightly. Instead perhaps we ought to
have it in some security suite that is run off to the side and doesn't
introduce constant redness into the main dashboard.

There is also some unresolved complexity around baselining e.g. Chrome OS vs
Chromium OS's expected process tree (not identical) -- and possibly
differences even per-board -- that I want to sort out as well.  This got
back-burnered: there was a preference expressed to me to employ a
non-autotest based way to audit the process list, which works on non
mod-for-test systems.  Understandably, since that approach means we don't
have to whitelist "sshd" etc.  So my time has been going into the manual
test and the autotest sits as you found it.

Thanks for bringing this up!

jim

On Fri, Sep 24, 2010 at 10:15 AM, <kmixter@chromium.org> wrote:

> Reviewers: petkov,
>
> Message:
> This test has been failing because it's out of date.  Brought it up to
> date.
> I'm not sure what Jim's plans are with
> platform_ProcessPrivilegesComprehensive -
> why it's a separate test and why it's not in a suite, but since this one is
> in
> the nightly suite, fixing it.
>
> Description:
> autotest: Bring platform_ProcessPrivileges test up to date
>
> Change-Id: I1adf121dbdb021654a056d6828f4100d70804c0a
>
> BUG=5618
> TEST=Ran on dev and test farm machines
>
> Please review this at http://codereview.chromium.org/3391023/show
>
> SVN Base: http://git.chromium.org/git/autotest.git
>
> Affected files:
>  M
> client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
>
>
> Index:
> client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
> diff --git
> a/client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
> b/client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
> index
>
52d5e6f39ac9856dc57b425bbde03db7041b89b8..45ef171361c050aafada8249009ecd2a561dccf4
> 100644
> ---
> a/client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
> +++
> b/client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
> @@ -70,16 +70,19 @@ class platform_ProcessPrivileges(site_ui_test.UITest):
>
>     def run_once(self):
>         self._failed = []
> -        self.check_process('candidate_window', user='chronos',
> do_login=True)
> +        self.check_process('cashewd', user='cashew')
>         self.check_process('chrome')
> -
> +        self.check_process('cryptohomed', user='root')
>         # TODO(mazda): Change the user value to 'messagebus'.
>         # 201 is a uid of messagebus. ps command displays 201 as the
>         # user name for some reasons (bug of the ps command?).
>         self.check_process('dbus-daemon', user='201')
> -
> -        self.check_process('ibus-daemon', user='chronos', do_login=True)
> -        self.check_process('ibus-memconf', user='chronos', do_login=True)
> +        self.check_process('flimflamd', user='root')
> +        self.check_process('metrics_daemon', user='root')
> +        self.check_process('powerd')
> +        self.check_process('rsyslogd', user='root')
> +        self.check_process('udevd', user='root')
> +        self.check_process('wpa_supplicant', user='root')
>         self.check_process('X', user='root')
>
>         if len(self._failed) != 0:
>
>
>

[kmixter1, 2010-09-24 18:12:06]

OK - that makes sense.  I'll push this change.

On Fri, Sep 24, 2010 at 11:01 AM, Jim Hebert <jimhebert@chromium.org> wrote:

> platform_ProcessPrivileges is an older test (not authored by me) that spot
> checks just a few things (< 12).  For example, any processes it's not
> specifically configured to look for, which exist on the system, don't cause
> a test failure.  This makes it a pretty non-brittle smoke test and is good
> for build verification or similar.  I don't have anything to do with this
> test, but am glad to see it getting updated, thanks for doing that.
>
> I got a request to produce a test that accounts for all (> 100) process
> privileges on the system.  We looked at the existing test and it didn't meet
> this need. E.g. if there's a new root-owned process that the test has never
> seen before, we want to go investigate if we're slipping backwards in terms
> of system security hardening.  That's
> platform_ProcessPrivilegesComprehensive.  This type of test is extremely
> brittle, 99% of the time when something like this makes noise, a human
> reviews it and decides to update the test-expectations.  That's just the
> nature of what we've asked of it.
>
> That test has not been added to a suite yet. Due to the brittle nature with
> a repetitive review-update-baseline-try-again-tomorrow loop, it may not be a
> great candidate for sticking into the nightly. Instead perhaps we ought to
> have it in some security suite that is run off to the side and doesn't
> introduce constant redness into the main dashboard.
>
> There is also some unresolved complexity around baselining e.g. Chrome OS
> vs Chromium OS's expected process tree (not identical) -- and possibly
> differences even per-board -- that I want to sort out as well.  This got
> back-burnered: there was a preference expressed to me to employ a
> non-autotest based way to audit the process list, which works on non
> mod-for-test systems.  Understandably, since that approach means we don't
> have to whitelist "sshd" etc.  So my time has been going into the manual
> test and the autotest sits as you found it.
>
> Thanks for bringing this up!
>
> jim
>
>
> On Fri, Sep 24, 2010 at 10:15 AM, <kmixter@chromium.org> wrote:
>
>> Reviewers: petkov,
>>
>> Message:
>> This test has been failing because it's out of date.  Brought it up to
>> date.
>> I'm not sure what Jim's plans are with
>> platform_ProcessPrivilegesComprehensive -
>> why it's a separate test and why it's not in a suite, but since this one
>> is in
>> the nightly suite, fixing it.
>>
>> Description:
>> autotest: Bring platform_ProcessPrivileges test up to date
>>
>> Change-Id: I1adf121dbdb021654a056d6828f4100d70804c0a
>>
>> BUG=5618
>> TEST=Ran on dev and test farm machines
>>
>> Please review this at http://codereview.chromium.org/3391023/show
>>
>> SVN Base: http://git.chromium.org/git/autotest.git
>>
>> Affected files:
>>  M
>> client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
>>
>>
>> Index:
>> client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
>> diff --git
>> a/client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
>> b/client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
>> index
>>
52d5e6f39ac9856dc57b425bbde03db7041b89b8..45ef171361c050aafada8249009ecd2a561dccf4
>> 100644
>> ---
>> a/client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
>> +++
>> b/client/site_tests/platform_ProcessPrivileges/platform_ProcessPrivileges.py
>> @@ -70,16 +70,19 @@ class platform_ProcessPrivileges(site_ui_test.UITest):
>>
>>     def run_once(self):
>>         self._failed = []
>> -        self.check_process('candidate_window', user='chronos',
>> do_login=True)
>> +        self.check_process('cashewd', user='cashew')
>>         self.check_process('chrome')
>> -
>> +        self.check_process('cryptohomed', user='root')
>>         # TODO(mazda): Change the user value to 'messagebus'.
>>         # 201 is a uid of messagebus. ps command displays 201 as the
>>         # user name for some reasons (bug of the ps command?).
>>         self.check_process('dbus-daemon', user='201')
>> -
>> -        self.check_process('ibus-daemon', user='chronos', do_login=True)
>> -        self.check_process('ibus-memconf', user='chronos', do_login=True)
>> +        self.check_process('flimflamd', user='root')
>> +        self.check_process('metrics_daemon', user='root')
>> +        self.check_process('powerd')
>> +        self.check_process('rsyslogd', user='root')
>> +        self.check_process('udevd', user='root')
>> +        self.check_process('wpa_supplicant', user='root')
>>         self.check_process('X', user='root')
>>
>>         if len(self._failed) != 0:
>>
>>
>>
>