Support multiple server profiles about ashirt HOT 4 CLOSED

General thoughts to the posed questsions.

1. This is probably a good idea, but technically, root directories don't need to be shared. Filenames are random (though we could certainly improve the randomness of them), and name collisions shouldn't be an issue.
2. There are 2 options open to us:
   1. Revise certain tables to indicate which server this asset belongs to
   2. Create a separate database for each server
      A separate database might be represented either as a separate file on the computer, or as a separate set of tables in the same file -- some research is needed here to see if there are pro/cons to these solutions, or if a single file is even possible with sqlite
3. A new menu option is probably the easiest to implement, in addition to the easiest for the user to find. An alternative would be to stick this in the settings menu somehow, and to have the user open up the settings to switch to a saved settings profile.
4. Possibly but it would be odd. The best solution here is to allow this to happen (though this kind of suggests that updating the db tables is the better approach, rather than separate databases), and provide a filter in the evidence manager to narrow to a specific server
5. Largely, this is not that complicated, though it does help to have a plan. In terms of raw transitioning of data, it's really just a simple javascript file conversion and a more complex file movement exercise. For files, I think we can just remap as so: path/to/baseDirectory/$opSlug => path/to/baseDirectory/$serverName/$opSlug. To do this, we'll want to first create a random directory name in baseDirectory (and repeat this process until we have one), and then move everything inside that directory. Then, rename that to a proper name -- what, I'm not entirely sure.

Some other thoughts:

1. Servers don't inherently have a name, so I suppose we'll need to rely on users to specify valid names for servers. As such, we'll need to prompt the user for a name/directory for that server, and we'll want to avoid a naming conflict with whatever operations already exist in that directory.
2. This is going to have an affect on aterm as well, as it'll likely need something similar

from ashirt.

Just as a note about how we can handle the config structure. One possible solution is a simple mapping between what we have into two sections: what is universal data, and what is specific data to a server. As a thought:

{
  "version": int, // Universal going forward -- this will be how to determine which config file is relevant
  "evidenceBase": string, // parent directory for where evidence will go (current evidenceRepo)
  "screenshotAreaCmd": string,
  "screenshotAreaCombo": string,
  "screenshotWindowCmd": string,
  "screenshotWindowCombo": string,
  "captureCodeblockCombo": string,
  "servers": [
    {
      "serverName": string, // user-specified name for a server.
      "apiURL": string,
      "accessKey": string,
      "secretKey": string
    } // one of these for each profile
  ]
}

This structure should allow for some growth. We can emphasize more growth by versioning the server objects, though currently I don't think that's strictly necessary. Thoughts?

Edit:
We could also write these details to the database instead. In fact, all of the config could be written to the database, which might make transitioning to a different "config" file in the future much easier. The downside is two fold: harder to share server configs, and sqlite limitations. Potentially also harder to fix an issue if the config gets into a bad state. Thoughts on this?

from ashirt.

There are actually quite a few issues here that need to be addressed in order to accomplish this.

1. The database currently stores the path to each evidence. Users cannot move evidence, but they can change where evidence gets stored, so potentially there will be multiple base directories -- this alone is not an issue, but presents a complication for moving the data.
2. This change will likely need changes to where files are stored, the database, and obviously the config. The order of operations will need to be:
3. Database changes (These happen automatically on startup -- no way for the user to interact prior to running them)
4. Changes to where the files are stored, if we end up moving them
5. Config file changes
   As such, the database will have to dictate our decisions used elsewhere, if there's any coordination between those elements
6. Based on the above, there are two routes forward with regards to where files live:
7. consolidate all of the pieces of evidence, regardless of where they live, to where new evidence will live in the future
8. Leave all existing pieces of evidence where they are, and only place files in their "new" location if they are in fact new
   If we go with the latter route (or maybe even if we don't), we might want to expose this ability for users to migrate files via the application to where they "should" be located.
9. Migrating files is going to be inherently risky, due to naming collisions.
10. A user renaming a server is nontrivial, as we potentially need to perform file migrations, as well as database migrations. We'll probably want to have a physical name and logical name for the server, where one acts as the name on the hard drive, while the other acts as the presentation to the user within the application.

Right now, I'm thinking the easiest, and probably best, route forward is to:

1. Update the database to create a "default" server and to associate all evidence with the new server
2. Leave all existing evidence where it is
3. Update the config to it's v2 variant
4. Update where evidence gets stored moving forward.

This is going to pollute the user's hard drive a bit and make saving to a server a bit trickier (what if there's a server that's also an operation name for a different server?) but it's probably worthwhile. In a future version, we can work specifically on migration evidence, and allow users to trigger migrating evidence manually, rather than having it forced on them.

We may also want to look into universally unique file names to alleviate this concern moving forward. That's a bit of a pain from a user perspective, but maybe not appreciably worse than the random characters we currently use.

from ashirt.

Closing issue since we've decided this makes things too complex and is not a large enough use case to warrant the work

from ashirt.