Allow black/white listing of which plugins work with which profiles in trunk

[GoogleCodeExporter]

We need to consider how best to store which plugins work with which profiles.

I think it's probably a facet of the plugin to define which profiles it will 
work with, rather than of the profile to say which plugins it will work with.

In general, I expect plugins to whitelist which profiles they will work against 
(although we should probably allow general cases such as "all profiles < blah" 
or "all windows profiles", etc).

Any comments or suggestions on the on-going work, should be made here.  
Thanks...  5:)

Original issue reported on code.google.com by mike.auty@gmail.com on 31 Jan 2011 at 11:23

[GoogleCodeExporter]

AW mentioned that the original purpose of the meta-info was for something like 
this. There are actually still a few plugins which say "only for XPSP2" but 
they really work on more OS's than that. So maybe something similar to the 
meta-info with a list of the profile names for which the plugin works? 

Original comment by michael.hale@gmail.com on 31 Jan 2011 at 11:30

[GoogleCodeExporter]

BTW could we use something similar to address Issue 49 (output rendering with 
inheritance)?

Something like:

class PluginName(ParentClass):
    meta-info['profiles'] = ['WinXPSP2x86', 'Win7SP0x86']
    meta-info['output'] = ['text', 'html']

Original comment by michael.hale@gmail.com on 1 Feb 2011 at 3:16

[GoogleCodeExporter]

Possibly, but I'm not sure it's worthwhile.  Currently output types are 
detected based on whether a render_<type> function exists.  Saying that they 
don't rather breaks the ability to inherit and still work properly, and storing 
the information twice will lead to problems (this plugin says is can do text 
output, but can't).

I'm also not particularly a fan of the meta-info variable.  It allows people to 
add new bits of data whenever they feel like it and not necessarily think 
through the consequences/how best to store it/how it will affect all other 
plugins (as we've seen there's no requirement on it, so some plugins have it 
and some don't).  I'd sooner see one variable per-reason, and then a separate 
class to carry them all around if there's so many that we need it (and if we do 
it probably indicates a design flaw somewhere along the way).

Original comment by mike.auty@gmail.com on 1 Feb 2011 at 7:04

[GoogleCodeExporter]

Sorry for the bugspam, but better to get this right now than later once it's 
more in use.

Original comment by mike.auty@gmail.com on 4 Feb 2011 at 9:35

• Added labels: Milestone-1.5.x
• Removed labels: Milestone-Release1.5

[GoogleCodeExporter]

Issue 80 has been merged into this issue.

Original comment by mike.auty@gmail.com on 15 Feb 2011 at 9:36

[GoogleCodeExporter]

I dont really get the issue here. If a plugin (say pslist) does not work with a 
given profile (say Vista) what do we expect to happen if a user tries to use it?

1) Do we want the plugin to not be visible at all if the user selects Vista 
profile?
2) Do we want the plugin to say - er.. I dont work with this profile?
3) Do we just want an exception and backtrace?

Currently we have 3. Response 1 is bad because it confuses users  (hey im sure 
Volatility has a pslist somewhere?).

Response 2 is kind of user friendly - print "This command does nto work with 
this profile" but its basically the same as 3 - the user can figure out it 
didnt work by seeing an error.

Besides plugins have no idea what profiles they do or do not work with - much 
of the funtionality is actually in the profile and how it was generated. It 
doesnt really make sense for the command to keep a list of profiles its 
supposed to work on.

If we are really concerned about user friendliness we can just wrap the command 
in try: except and then swallow the error and print something bland - but I 
think this is really not a very useful thing.

I suggest this is not a bug.

Original comment by scude...@gmail.com on 1 Mar 2011 at 10:51

[GoogleCodeExporter]

Well, the problem will come when we have 800 plugins, and when the uses asks 
for --help, they get flooded with plugins that patently couldn't work with the 
image they're interested in (linux plugins for a windows image or windows 
plugins for a linux image).  If we're going to split those so that the user 
doesn't have to see them all at once, then why make it such a broad 
distinction, why not provide them with a list of plugins that they can use 
against the profile they've chosen.

This might also allow us to have two completely distinct plugins 
(windows.pslist and linux.pslist) which operate in completely different ways, 
but achieve the same effect.  This issue is an area to discuss that, so whilst 
it may not be a bug, it belongs in this tracker.

We are concerned about user friendliness when the user tries something that 
blatantly won't work, but there is a need for comprehensive backtraces when 
something really goes wrong.  Swallowing every exception's a bad idea, so 
figuring out how to distinguish between those events is what we're really 
trying to solve.

So in your example, I'd expect the plugin not to show up in --help if the Vista 
profile has been chosen, and if the users decides it exists and runs it anyway, 
it should say "This command does not work with this profile."

It makes no sense for the profiles to store which plugins work with them, since 
any new plugins would require a change to each and every profile they worked 
with.  That only really leaves the plugin having a restriction system (works 
with "older than vista") as the viable option.  So the two questions are:

a) Is this worthwhile?  Is there a different way to avoid bombarding the user 
with too many options/choices at once?  Can we find a clever way of allowing 
similar plugins for different operating systems (profiles) to have the same 
name?

b) If it is worthwhile, how could we most flexibly implement this and what 
problems will we face when we try?

Original comment by mike.auty@gmail.com on 1 Mar 2011 at 11:04

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

So the issue is more about command plugins querying the profile about rough 
capabilities. Maybe we should have a set of capabilities in the profile (like 
OS_TYPE = "linux", BIT_SIZE = 64 etc).

Then we can make the command plugin check if the profile has those capabilities 
to immediately tell that its not going to be able to run. Maybe then filter 
--help based on this.

Original comment by scude...@gmail.com on 1 Mar 2011 at 11:28

[GoogleCodeExporter]

Ok, so I think we're making progress on this when a while ago we introduced the 
metadata values on profiles.  This allows plugins to differentiate between 
profiles, and carry out their own white-/black-listing.

profile.metadata is a dynamically generated dictionary that should contain os, 
major and minor for every profile at a minimum (and may contain more).  I'm not 
going to mark this as fixed until our plugins do differentiate which OS they 
work on, and all the machinery's in place to do hiding on the help page, and 
error messages when the users tries something hairbrained...

Original comment by mike.auty@gmail.com on 21 Jun 2011 at 8:21

[GoogleCodeExporter]

update - scudette's meta info for linux plugins allows this already - merge 
from x64

Original comment by michael.hale@gmail.com on 15 Dec 2011 at 9:20

[GoogleCodeExporter]

Ok, here's a patch that only displays the appropriate plugins in --help if 
they're valid for the profile.  It doesn't yet prohibit attempting to use the 
disabled plugin, it just won't show it as part of help.  An additional list of 
disabled plugins is provided is -v or --verbose is used.

It's a little rough, so currently makes most plugins windows-only, and 
connections and netscan are profile specific.  There may be other plugins that 
are only useful on windows, I haven't had a complete think about this, but the 
idea is to get some people checking it, and make sure it seems ok/will work out 
if we apply it to trunk...

Original comment by mike.auty@gmail.com on 30 Apr 2012 at 12:03

• Changed title: Allow black/white listing of which plugins work with which profiles in trunk

Attachments:

• volatility-plugin-profile.patch

[GoogleCodeExporter]

So I believe this has now hit trunk as of r1718.  It's not strong blacklisting, 
but it's present and should cut down the help list without stopping users from 
trying crazy things if they want to.  It'll be quite easy to make it a hard 
restriction, but I'm not certain that's a good idea.  Feel free to reopen this 
if you want a guaranteed black/white list, but otherwise I'll mark this as 
FIXED.  5:)

Original comment by mike.auty@gmail.com on 21 May 2012 at 11:01

• Changed state: Fixed