There are a number of concerns one must address when trying to secure a client Windows OS machine running Aston; things to consider include the scope of what you wish to achieve, and how effectively you wish to lock down your system for your users. Each will greatly determine to what level you will have to focus your energies, and ultimately whether Aston is actually the best shell to be running for a system's intended function.
First, a word of caution. As with all systems, regardless (to some extent) of the operating system or shell, your setup is only as safe or secure as the lengths you employ to secure it. In many cases, a failure to plug a known hole will render all other attempts at security implementation useless, and a thorough knowledge of the operating system you intend to secure should be gained before any attempt to secure them. This document is NOT intended to cover any software configuration other than Aston replacement shell and no responsibility for the success or failure of measures indicated herein is made. A simple flaw, insufficient permission policies (such as for software installation or directory & file access), or a determined "user" can compromise most systems. It is assumed that the system administrator responsible for configuring Aston will have already made every attempt to secure the underlying operating system file and directory structure.
The most popular reason for the choice of Aston as a secure interface is the ease with which the various components of the desktop, screen-side toolbars, and "start" menu can be configured. These, therefore, are typically the prime areas where a system administrator is concerned, and each is addressed in turn, with exceptions noted below each section.
The first item to address is a comprehensive desktop layout, with all the required desktop icons having already been put in place. Each element should be locked in place, and fully and accurately configured. This is because once all of the elements that comprise your user interface have been configured, it is ESSENTIAL that the Aston.rc file is made read only and hidden. Once the .rc file is locked, there is no way to change the look of the system without administrator permissions - something all good administrators wish to minimize.
No access to the file explorer (My Computer), Control Panel, Run command, or Desktop folder via a desktop icon should be given. The read only status of the Aston.rc file will prevent any new icons from being added to the desktop.
THE "START" MENU & TASKBAR
This must be thoroughly "cleaned" before you lock the Aston.rc file. All elements such as access to the Aston tools, run command, CMD.exe or command.exe should be removed, as well as any links to the file explorer, settings folder, or administrative tools. Access to the Aston Master program can still be made by right clicking the start button or Aston taskbar icon, but a locked Aston.rc file will prevent any changes from taking effect.
ALL FILES AND DIRECTORIES NOT HIDDEN OR WITH APPROPRIATELY SET PERMISSIONS CAN BE ACCESSED VIA INTERNET EXPLORER AND THE START MENU! Typing file:/// with the appropriate drive letter & directory in the address bar of IE (or the File>Open command), OR by right clicking directory content within the "programs" section of the "start" menu, and choosing "new link" will give full access to unsecured files and directories. No solution for this is known at this time, and it is not known by the author whether this behavior is a "feature" of other browsers. It is for this reason that it is not recommended that Aston replacement shell be used as a secure user interface on a non-NTFS system. Files and directories may also be accessed by creating links within the quick-launch bar, and it is recommended that the quick-launch plug in be deactivated on a secured system for this reason. All required quick-launch items may easily be added to a screen-side toolbar.
Another issue to remember is that permissions must be carefully set for every directory on the subject system. The full available structure is visible through any "file > open" command within applications such as office etc, and the full right click context menu is available, with all of the attendant implications that this behavior brings. Again, the subject system must be secure at the operating system level, before attempting to secure Aston.
Additionally, if you intend to implement any registry changes to further secure your Aston interface, ensure you are logged in to the Logon ID that will be user for the secure interface, and that you are using the Aston shell as your default for that logon. Registry changes should be made first, prior to locking down Aston. Also worth noting is that standard security methods that are typically employed via the registry often do not work under keys marked \Explorer…\. Many such keys are not typically loaded or referenced under Aston (exceptions listed below).
To close almost all the possible holes, admin can install the restricted version of Aston. These are available from link:
These versions have the following (lack of) features:
How to install?
Functional exceptions to the registry policies include \HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\
Item Type: REG_DWORD
NoRun=1 Remove Run command from Start menu (AND from Task manager in winNT/2000/XP!!!)
NoClose=1 Removes the Shut Down item
RestrictRun=1 Run only allowed Windows applications
Read the MSDN article http://support.microsoft.com/default.aspx?scid=KB;en-us;q151176
(Policy Registry Entries (Default User)) for more information on this topic.
written by D.L. Olesch-Williams (aka The_PC_Mechanic)