I have been tasked with writing entries to the Windows security log. The entire project is Win32 C++ code. I have already written (with help from various online resources) a logging class that handles registration, deregistration, and code for executing the ReportEvent() call. Also, I've done the mc.exe and rc.exe steps for my event logging, if that helps establish where I'm at in the project.
My question is a multi-parter:
I've noticed at Filling Windows XP Security Event Log that there are some who believe this is not allowed by Windows. Others ( How to write log to SECURITY event Log in C#? ) imply otherwise. Possible or not?
If it is possible, how to get it to write to the security log. Is it as simple as specifying "Security" as my source name when calling RegisterEventSource()?
As far as deregistration, when should that occur? When the app is uninstalled? When the app closes? When the log entry is written?
How do I look up my log entries? I look in the Windows Event Viewer, but I don't see the entries I add with my test app, despite all the appropriate return values from the system calls. Where would I look up the events that I specified with a source name of "yarp" when I made my call to RegisterEventSource()?
For the moment, I'll just deal with the first question, because the answer to that probably renders the rest irrelevant.
Only Local Security Authority (lsass.exe) can write to the security log. This isn't a matter that something else attempting to get the privilege will fail -- it's a matter of there not being a way for anything else to even request the privilege at all (and this is by design).
From there, about the only answer to your other questions is "Sorry!"
Related
I have been dabbling with working nicely with UAC for a while and I found about a few things:
With UAC enabled, a program in the Startup folder, that requires to be run as admin (say by an embedded manifest), cannot be run according to this Stack Overflow thread.
Another method of running a program at startup is by creating a key containing the path to that application in: HKLM or HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run or HKLM or HKCU\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run in 64 bit machines.
Yet another method is using the task scheduler setting the Run with highest privileges option. This is the only method that bypasses the problem stated in point 1.
Coming from a Linux background, I had no clue about all these admin rights related problems. If someone can list out scenarios which absolutely need administrator privileges, it would be of great help!
I'm asking this because when I'm developing some application, I keep encountering several problems during implementation mostly because my application required admin rights when it shouldn't.
If I know, at design time, all possible scenarios that require admin rights, I could possibly design a common service for all my applications that takes care of all the administrator tasks (I think services are the Windows way of doing things like this).
There really isn't a list of scenarios or API function calls that require elevation. Your best option will probably be to focus on what API calls require elevation. The reason for this is that it may be required only if certain values are passed to the function. For instance CreateFile can create a file in your home directory without elevation but requires it for creating a file in C:\Windows. If the directory is provided through user input the only way you can know if elevation is required is to check the error code when the call fails. If elevation is required the function will set the error status to ERROR_ACCESS_DENIED and return a value indicating failure.
I am developing an application using Django that works similar to a project manager. For this reason, the system should be capable of storing information about everything. When I say everything I refer to the actions the users do, the errors that occurred while doing an action, etc.
I have a class Log and one of its attributes is called action_type, this attribute specifies what kind of action just happened. I am supposed to have 5 kinds of types:
INFO: this log stores the information related to user's actions such as creating a project, create other users, etc.
DEBUG: should store comments made by the developers that will allow them to detect errors.
ERROR: shows errors that occurred in the system but they don't affect the system's functionality.
WARNING: it's for potentially damaging actions.
FATAL: unexpected errors, exceptions and security breaches.
I can only come up with logical logs for INFO.
Could you tell me some reasonable logs that I should include in this and the other categories?
The answer will depend greatly on exactly what your application does, but my basic approach is this:
Each time you get ready to log an event, just think about the event and it will be clear where it belongs. Did it kill your application? It's fatal. Did it prevent something from working correctly? It's an error. Could it prevent something from working, and did we just get lucky this time? It's a warning. Does anyone care? Info. Otherwise, if you still need to log it, it must be for debugging purposes.
In your particular context, it sounds like you might only be trying to log user actions. If that is the case, the only actions that could be fatal would be ones for which you don't provide an undo option (or, I suppose, if the user is able to order a piano bench and a length of strong rope through your application). I also couldn't really imagine any debug-level logs coming from user actions. Because of this, I assume you will be logging code level events in addition to user actions.
FATAL: This should only appear in the logs when your application actually crashes, and possibly alongside 500 responses. You might generate these within your wsgi application in a catch-all, only when the process would otherwise have died.
ERROR: Likely tied to http error responses. This is typically for errors caused by something outside your application. Things that happen in your code are probably expected and <= warning level, or unexpected and fatal. Errors might be a 404 from the user making a typo in a url, validation errors on form submission, or authentication errors. From the other direction, errors might be returned from remote web services that you contact or IO errors from the os.
WARNING: For things that don't break anything, but that might bite you if you keep it up. Examples are using deprecated apis and anywhere something only worked because of the default (time zone, character encoding, etc). Maybe certain input values result in warnings, too, like setting a due date in the past.
INFO: General, healthy operation. Someone created a database row (a new project or a task?), created an account, logged in or out, a socket was successfully opened, etc.
DEBUG: Just what it says. Output that you will usually turn off once the code is working correctly. Method entry/exit, object instantiation, field values at various points in the code, counters. Whatever you need to figure out why your program is crashing right now, as you work on it.
I want to monitor when a key is changed/added/deleted to the registry whenever application is being installed or removed. I have tested the sample code from the msdn(link) and it works fine.
But the problem is that it does not tell me which key has actually been modified/added/deleted. How can i retrieve this information using c++?
There are only 3 ways, none of which is both easy and adequate:
RegNotifyChangeKeyValue:
Doesn't give you the info you need, but is very easy to use.
EVENT_TRACE_FLAG_REGISTRY which is part of Event Tracing for Windows
which is what ProcMon uses. It works well, but it's quite difficult to use.
I'm not sure exactly how to use it myself, but if I figure it out I'll post it here.
CmRegisterCallback:
Requires kernel-mode driver, which is a pain in 64-bit.
But it's the most perfect solution otherwise.
Unfortunately Event Tracing for Windows (EWT) does not allow to see full key path in the event. You get only a partial key name and a strange handle with is actually a key control block. It's not so simple to get information from this block.
Yes the process monitor uses EWT, but it does not use Windows Kernel Trace as a provider.
We've got an old legacy win32 service, developed with C++, and we've just recently noticed that when the service starts up and stops, there is an informational message in the event logs about our missing event descriptions. To be more precise, the message looks like this:
The description for Event ID 0 from source [application] cannot be
found. Either the component that raises this event is not installed on
your local computer or the installation is corrupted. You can install
or repair the component on the local computer.
So we understand what this means, basically we're missing a library which has a message table compiled into it. This way when the event ID for changing status (start/stop) arrives, it can look up the message and print it in the event logs.
The question is, for these universal messages (changing status etc) which pretty much every service is going to have, surely there are default message table that we can use, rather than having to go to the trouble of creating another project, just for this, adding registries and updating our installer.
Seems like a lot of hassle for something that should surely be a default somewhere? Like the standard win32 error messages?
I've created a number of managed services in the past, and I'm pretty sure we didn't need to do anything like this before!
So to wrap this up, I guess the answer is that the a new message table/file is always required, regardless (so no there are no default messages you can use), so I'll just have to chuck in a message table into my services resource file and add a registry entry to the installer.
Still find it baffling thought that every native service has it's own 'service has stopped/started' message...!
Thanks!
I've encountered the following problem pattern frequently over the years:
I'm writing complex code for a package comprised of a standalone application and also a library version of the core that people can use from inside other apps.
Both our own app and presumably ones that users create with the core library are likely to be run both in batch mode (off-line, scripted, remote, and/or from command line), as well as interactively.
The library/app takes complex and large runtime input and there may be a variety of error-like outputs including severe error messages, input syntax warnings, status messages, and run statistics. Note that these are all incidental outputs, not the primary purpose of the application which would be displayed or saved elsewhere and using different methods.
Some of these (probably only the very severe ones) might require a dialog box if run interactively; but it needs to log without stalling for user input if run in batch mode; and if run as a library the client program obviously wants to intercept and/or examine the errors as they occur.
It all needs to be cross-platform: Linux, Windows, OSX. And we want the solution to not be weird on any platform. For example, output to stderr is fine for Linux, but won't work on Windows when linked to a GUI app.
Client programs of the library may create multiple instances of the main class, and it would be nice if the client app could distinguish a separate error stream with each instance.
Let's assume everybody agrees it's good enough for the library methods to log errors via a simple call (error code and/or severity, then printf-like arguments giving an error message). The contentious part is how this is recorded or retrieved by the client app.
I've done this many times over the years, and am never fully satisfied with the solution. Furthermore, it's the kind of subproblem that's actually not very important to users (they want to see the error log if something goes wrong, but they don't really care about our technique for implementing it), but the topic gets the programmers fired up and they invariably waste inordinate time on this detail and are never quite happy.
Anybody have any wisdom for how to integrate this functionality into a C++ API, or is there an accepted paradigm or a good open source solution (not GPL, please, I'd like a solution I can use in commercial closed apps as well as OSS projects)?
We use Apache's Log4cxx for logging which isn't perfect, but provides a lot of infrastructure and a consistent approach across projects. I believe it is cross-platform, though we only use it on Windows.
It provides for run time configuration via an ini file which allows you to control how the log file is output, and you could write your own appenders if you want specific behaviour (e.g. an error dialog under the UI).
If clients of your library also adopt it then it would integrate their logging output into the same log file(s).
Differentiation between instances of the main class could be supported using the nested diagnostic context (NDC) feature.
Log4Cxx should work for you. You need to implement a provider that allows the library user to catch the log output in callbacks. The library would export a function to install the callbacks. That function should, behind the scenes, reconfigure log4cxxx to get rid of all appenders and set up the "custom" appender.
Of course, the library user has an option to not install the callbacks and use log4cxx as is.