New
#51
Message Boxes
I am familiar with toast notifications.
I was responding to a comment of yours about interaction with users that required user decisions to be made. Toast notifications do not achieve that.
- By the way, Toast notifications do not necessarily necessitate additional installations. The module you discuss is a choice you have made not a necessity.
- Any additional 'system' installations or setting up complicate the tool significantly.
Use of built-in dialogs*** can be written into batch files to avoid complicating the user experience. But I still think that no user interaction is needed.
- I do not think that any in-process decisions are required because I think the user wants any detected Ghost task to be deleted and, possibly, the results recorded in a log.
- If a log is to be kept, the user will have to be asked which folder to put it in.
- Both these can be pre-prepared decisions entered manually in a text file beforehand and the batch file can read those lines.
- - The user can be given the template text file and can be told to keep it in the same folder as the tool itself.
- - I always name these text files *.ini merely as a marker of their nature.
*** If user interaction were to be required then customised title & text built-in dialogs can be called by the batch file without any installations being required.
- But the button labels are limited to
Use of Task scheduler by malware
This is a whole new ball game. I don't think you should get into this game.
- I do not think that malware can set up a task to run as the System user without having impersonated the System user in the first place.
- I do not think that malware can impersonate the System user without already having achieved elevated status
- WD and UAC attempt, amongst other things, to prevent malware achieving elevated status.
- If malware has achieved elevated status then all bets are off.
- By the way, there are always claims about malware being able to achieve elevated status without the user even knowing if that user is an Admin user and UAC is at its default level.
- - I protect myself from this by keeping UAC at its maximum setting. Despite an occasional claim to the contrary, I have not seen evidence of malware being able to counter this precaution.
- - I could protect myself from this by following MS's half-hearted advice not to routinely use an Admin account for day-to-day computing anyway.
SuppressGhostTasks Q1
I was referring to the TS task that we create in order to detect the Ghost Task.
- Since we create a task that runs at user login, TS does not prevent use of a user interface.
- The Ghost tasks do get prevented by the WpTasks tool without any elevation or System user impersonation being required.
- Any attempt to impersonate the System user for the SuppressGhostTasks task would require setting up and would probably require use of PSExec. But none of this is required to do the job we have been talking about.
About "Also worth exploring is the issue of what we allow ordinary users to do in regards to these tasks" and "Optimally I think the following should happen ..."
- "should we allow ordinary users to delete ... these tasks?" Yes, just as we already do with the existing batch file.
- "should we allow ordinary users to ... disable these tasks?" We have no control over GhostTasks so we cannot disable them if I have understood the WpTasks tool correctly.
- The task we create runs unelevated. We already know that that is sufficient to do the job.
- The SuppressGhostTasks task we create already runs for every user as that user is logged on. No further action is necessary.
- I do not believe there is any requirement to have these Ghost tasks {we still do not know whatt hey actually do so no requirement for them can possibly exist} so the only logical user action is to delete them [OK, delete the thing that creates the instances we see of them].
My assessment of where we are
I think the combination of the WpTasks.exe tool, the batch file & the TS task .xml file are already sufficient and require no more than tidying up other than the possible addition of an .ini file so a log file Y/N decision & a log file location can be specified by the user. A Help file would also be worthwhile
The text file you have referred to could usefully be in two parts, two files - Inital setting up, Discussion of the GhostTasks topic
- - I think pdf would be an appropriate format because it would allow formatting & illustrations
- - I think that splitting the Help into two files would be worthwhile because they are two hardly-related topics and putting them both together would risk creating a complicated whole that would distress users.
- The SuppressGhostTasks task we create needs no particular alteration.
- - We could put some thought into the best frequency for running the task.
- - We could usefully add a description but that's a minor thing.
- The SuppressGhostTasks batch file could be augmented with an .ini file in the same folder so the user can specifiy a log file Y/N decision & the location of any required log.
- - But I am still not convinced of the need for a log.
- - And I still do not see any need for the user of any dialog boxes / notifications
- We can tell the user to put the WpTasks.exe tool, the batch file & the .ini file in the folder C:\Tools\TS\GhostTaskSuppressor
- - We can tell users to create & set up permissions for C:\Tools using the procedure in the annex to Make Task scheduler run a batch file minimised and with a specific icon - TenForums
- - We can tell users to create the subfolders TS\GhostTaskSuppressor
- - We can provide the .xml file and tell users how to import it into Task scheduler.
- - We could, in the future, consider automating these 'setting up procedures' by providing an installation batch file but we would definitely need the assistance of somebody who knows how to use Icacls to set the permissions for C:\Tools
Denis
Last edited by Try3; 03 Jun 2020 at 12:27.
Quote
