microsoft / AttackSurfaceAnalyzer

Attack Surface Analyzer can help you analyze your operating system's security configuration for changes during software installation.
MIT License
2.69k stars 273 forks source link

[Request] Installer #345

Open poortom1004 opened 4 years ago

poortom1004 commented 4 years ago

There is no MSI provided. Can you please start providing MSIs with your releases? Previous versions of ASA included MSI packages.

gfs commented 4 years ago

Hi Thomas,

To help me understand better. What is your use case that requires .msi?

Gabe

-------- Original Message -------- On Jan 9, 2020, 11:04 AM, Thomas Garrity wrote:

There is no MSI provided. Can you please start providing MSIs with your releases? Previous versions of ASA included MSI packages.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

poortom1004 commented 4 years ago

I think you were the one who mentioned this was going to be worked on in the future in a separate issue I had reported.

poortom1004 commented 4 years ago

But the use case would be to use best practice of software management on a Windows platform. MSIX would actually be preferred as that is the newer technology and seemingly way forward according to Microsoft.

gfs commented 4 years ago

How do you envision accessing ASA after it is installed? Do you want it added to the PATH?

poortom1004 commented 4 years ago

I haven't gotten into the command line for this as of yet but likely would once we have a mechanism for deploying a MSIX package, so I can't yet comment on the use of the PATH variable.

gfs commented 4 years ago

I'm trying to get at what the msix itself will give you as a user. ASA must be run from the command line so it's not actually made simpler for the user to run it by simply installing it. The only benefit I can think of would be to install and add it to the path.

So I'm unsure what benefit you believe you would derive from an MSI package. There is no need for an installer. You can run the file directly out of the zip package.

-------- Original Message -------- On Jan 9, 2020, 1:58 PM, Thomas Garrity wrote:

I haven't gotten into the command line for this as of yet but likely would once we have a mechanism for deploying a MSIX package, so I can't yet comment on the use of the PATH variable.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

poortom1004 commented 4 years ago

ok I guess I'm not following you when you are talking about "adding to the PATH". But from an MSI/MSIX perspective, it allows the executables and scripts to be signed and therefore trusted by the operating system without any exceptions needing to be made. It also allows for a clean uninstall. There's no need to hunt down the source files to remove them. The Operating System knows exactly where everything is kept which is referenced from the installer. Clicking uninstall will remove files, registry keys, services, etc... that were installed by the product. I understand this ASA tool only contains files, but that doesn't change anything. It also would uncomplicate things by placing shortcuts after installation, so that a user does not need to sift through nonsense (dll) files they don't need to be concerned with, and they don't need to read to documentation to discover the name of the file they need to execute.

This is the message I get when running that .bat file to launch the GUI and I had to click an extra button just to get to that screen, which may not be obvious to someone else. ASA 1

Using MSI/MSIX allows for quick and easy distribution and removal of software.

I'm not trying to offend you but this distribution seems out of place from Microsoft standards.

poortom1004 commented 4 years ago

Also here's the problem with using a web interface that requires admin permissions. Modern browsers don't understand the concept of "run-as". So you need to log into a machine with local administrative privileges, so it violates the whole principle of least privilege.

gfs commented 4 years ago

ok I guess I'm not following you when you are talking about "adding to the PATH".

ASA should be run from a command prompt. Adding it to the path adds a shortcut for the command prompt.

But from an MSI/MSIX perspective, it allows the executables and scripts to be signed and therefore trusted by the operating system without any exceptions needing to be made.

Our binary is signed.

It also allows for a clean uninstall. There's no need to hunt down the source files to remove them.

No files are installed by ASA. Everything remains in the folder. To uninstall just delete the folder.

This is the message I get when running that .bat file to launch the GUI and I had to click an extra button just to get to that screen, which may not be obvious to someone else.

I didn't realize the .bat files were now triggering smartscreen. I'll publish an update that removes them. You should just run Asa.exe directly from a command prompt (or powershell).

Also here's the problem with using a web interface that requires admin permissions. Modern browsers don't understand the concept of "run-as". So you need to log into a machine with local administrative privileges, so it violates the whole principle of least privilege.

You don't need to run your browser as administrator - you only need to run ASA as administrator. Open an administrator powershell and run "asa.exe gui" to start the GUI, or refer to the readme for usage.

My recommendation is that you switch to lanching ASA from powershell. We will consider this for future releases.

poortom1004 commented 4 years ago

Here is the guidance on the wiki that tells me how to use the tool. asa

There is no mention of using PowerShell to launch on the wiki. Seems rather odd that you would use PowerShell to run a bat file though... In fact out of the 10 years I've been using PowerShell, I've never done that. I've run ps1 files from PowerShell though.

gfs commented 4 years ago

Correct. My recommendation is to launch the binary (Asa.exe) directly in powershell. If you want to follow the directions in the Wiki those work too, but launching directly shouldn't trigger smart screen.

-------- Original Message -------- On Jan 10, 2020, 2:53 PM, Thomas Garrity wrote:

Here is the guidance on the wiki that tells me how to use the tool. asa

There is no mention of using PowerShell to launch on the wiki. Seems rather odd that you would use PowerShell to launch a bat file though...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

gfs commented 4 years ago

We now have a one line installer if you have .NET Core already installed on your system.

dotnet tool install Microsoft.CST.AttackSurfaceAnalyzer.CLI --version <latest version>

Right now that is

dotnet tool install --global Microsoft.CST.AttackSurfaceAnalyzer.CLI --version 2.2.10-beta-g106685ca9a

After that to run Attack Surface Analyzer just type asa <command> on the command line or powershell.

Once 2.2 is out of beta you will not longer have to specify the version number and it will automatically give you the latest.

See https://www.nuget.org/packages/Microsoft.CST.AttackSurfaceAnalyzer.CLI/.

gfs commented 4 years ago

@poortom1004 Attack Surface Analyzer 2.2 is now out with a one line install/uninstall using .NET Core.

First install .NET Core SDK.

Then run dotnet tool install -g Microsoft.CST.AttackSurfaceAnalyzer.CLI

This will add asa to your path so you can run it directly from the command line or powershell.