Logging, Login API and SSPI

[James V]

Hi,

I am trying to add logging capabilities to a Windows(2000/XP/2003)
application that can run under any user context(not neceseraly a member of
admin).

The problem is that every time a diffrent user will run the application, the
log files would be created/written under his credentials.

Some users can have limited permissions and not allowed to access various
parts of the file system.
Further more, if a limited user created/written a/to file he has permissions
to view and change it and
I do not want limited users to be able to view modify the log files.

If I create the files with admin privilages, limited users will not be able
to write/modify them.

I could create a logging service that uses IPC to connect to the server
application and manage the loging for it, but it seems like an overkill.

I considered using a special user account that would be impersonated by our
application(using login API and SSPI ) and would do the actual log file
manipulation, but the problem is that login API and SSPI can require
certain privilged user permissions (SE_TCB_NAME ) for the impersonation to
work properly (The impersonation level does not allow resource access).

Is there any way around the login API and SSPI limitations?
Is there any way to set application level(not user level) permissions ->
allow only a certain application to write to a file?

Any ideas comments would be appreciated.

Thank you,

James

 

[Ben Voigt]

Hi,

I am trying to add logging capabilities to a Windows(2000/XP/2003)
application that can run under any user context(not neceseraly a member of
admin).

The problem is that every time a diffrent user will run the application,
the log files would be created/written under his credentials.

Some users can have limited permissions and not allowed to access various
parts of the file system.
Further more, if a limited user created/written a/to file he has
permissions to view and change it and
I do not want limited users to be able to view modify the log files.

If I create the files with admin privilages, limited users will not be
able to write/modify them.

I could create a logging service that uses IPC to connect to the server
application and manage the loging for it, but it seems like an overkill.

I considered using a special user account that would be impersonated by
our application(using login API and SSPI ) and would do the actual log
file manipulation, but the problem is that login API and SSPI can require
certain privilged user permissions (SE_TCB_NAME ) for the impersonation to
work properly (The impersonation level does not allow resource access).

Is there any way around the login API and SSPI limitations?
Is there any way to set application level(not user level) permissions ->
allow only a certain application to write to a file?

This would probably be possible with a device driver, which can then use the
process handle of the caller to checksum the executable and all libraries
and make sure they haven't been tampered with. Otherwise, the user will be
able to at least send arbitrary log messages.

Also, the user will always be able to view his own log messages, because the
process is running as his user account, he can read its memory, by calling
CreateProcess to start the process and get a full access handle to it, and
then ReadProcessMemory.

 

[Eugene Gershnik]

Hi,

I am trying to add logging capabilities to a Windows(2000/XP/2003)
application that can run under any user context(not neceseraly a
member of admin).

The problem is that every time a diffrent user will run the
application, the log files would be created/written under his
credentials.
Ok.

Some users can have limited permissions and not allowed to access
various parts of the file system.
Further more, if a limited user created/written a/to file he has
permissions to view and change it and
I do not want limited users to be able to view modify the log files.

What is the problem? Write a separate log file for each user under
CSIDL_LOCAL_APPDATA.

 

[James V]

Hi Ben,

Thank you for your answer.

I guess I won't take that path.

But I believe that if application level permissions were to be incorporated
into the operating system, such a mechanism could be made to be safe.
Because for example, such a mechanism would not allow a non admin or
application owner to manipulate a process by means of ReadProcessMemory etc.

 

[James V]

Hi Eugene,
Thank you for your comment.

There are a couple of problems with writing logs to CSIDL_LOCAL_APPDATA .
1. The user would have access to them.
2. The log files would be all over the place instead of in one centralized
location.

 

[Guest]

Have you considered the trace API? (also known as "WMI trace") ?
--PA

 

[Eugene Gershnik]

Hi Eugene,
Thank you for your comment.

There are a couple of problems with writing logs to
CSIDL_LOCAL_APPDATA . 1. The user would have access to them.

Why not? They are his log files produced as a result of what he was doing.
Why do you want to deny him a chance to troubleshoot?

2. The log files would be all over the place instead of in one
centralized location.

First of all that's a good thing from security perspective. You cannot have
it both ways: secure and single location. Second why do you care? If you are
concerned about how to get them from a customer site, write a utility that
does it.

 

[James V]

Hi Pavel,

Thank you for your comment.

That looks interesting but it seems that "WMI trace" is meant to be used in
drivers(requires Pointer to a device object) and had limited number of
instances(32):
http://msdn2.microsoft.com/en-gb/library/aa490396.aspx

I have a user mode application that can be ran by non privileged users.

Am I wrong and if so can you direct me to any other link you have on the
subject?

 

[James V]

Hi Eugine,

Thank you for your answer.

My comments below:

1. While I do not care if the user sees his logs, I do not want him to be
able to change them.
It is a requirement that any operation done by the software would be
saved for later possible inspection by an admin.

2. We would like to have a centralize log directory where admins can read
and monitor the logs.
It should be something similar to IIS logs. do you know how Microsoft
implements IIS logging?

 

[James V]

It should be somethig similar to IIS logs. do you know how Microsft
implements IIS loging?

 

[Alexander Nickolov]

For starters IIS is a service running under the system
account. Once you are trusted, you can do anything
you want...

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: (e-mail address removed)
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

 

[Eugene Gershnik]

Hi Eugine,

Thank you for your answer.

My comments below:

1. While I do not care if the user sees his logs, I do not want him
to be able to change them.
It is a requirement that any operation done by the software would
be saved for later possible inspection by an admin.

Ok, but then simply saying log is misleading here. What you mean is usually
called audit log.

2. We would like to have a centralize log directory where admins can
read and monitor the logs.
It should be something similar to IIS logs. do you know how
Microsoft implements IIS logging?

Well what you are describing requires a log service running under a
privileged account that accepts log messages from applications. Simple COM
service will do in your case. Some OSes had such facility built in for years
but Windows didn't (I think there is something in Win2k3 or possibly
Longhorn) so you will need to roll out your own.

 

[James V]

When you say COM service do you mean a WinNT service that can be used from a
COM object?

 

[Eugene Gershnik]

When you say COM service do you mean a WinNT service that can be used
from a COM object?

Well, yes. A COM server can be deployed as a service. Any good book on COM
will show you how.