Process Name

NTFSD
2

Just the base filename of the process or the full
pathname? The former you can get using the simple
method demonstrated in FileMon, the latter you cannot
get without walking through several levels of
undocumented internal data structures. Search the
mailing list, there are many messages on this topic.

— Ken Galipeau wrote:
> During a IRP_MJ_CREATE, who can one get the process
> name or process
> executable file name of the process opening the
> file?
>
> Thanks,
> Ken
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@nryan.com
> To unsubscribe send a blank email to
> %%email.unsub%%
>

=====
- Nicholas Ryan

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

3

“Nicholas Ryan” wrote in message news:xxxxx@ntfsd…
>
> Just the base filename of the process or the full
> pathname? The former you can get using the simple
> method demonstrated in FileMon, the latter you cannot
> get without walking through several levels of
> undocumented internal data structures. Search the
> mailing list, there are many messages on this topic.
>

If the “simple method demonstrated by FileMon” is still (I haven’t looked at
the code for years) to get the ImageName from some hard-coded offset in the
EPROCESS, this is a bad idea. And walking through several layers of
internal data structures is an even WORSE idea.

Specifically, the offset to the ImageName has (really) changed between O/S
versions. Who knows, maybe it could change between service packs.

Not to mention the issue that if you get just the ImageName, what does that
really tell you? Surely you won’t base a security decision on this?

The way I understand it, presently the only way to do this safely is from
user mode. There may be a safe kernel-mode facility for doing this in the
future. I agree that it certainly would be useful.

Peter
OSR

4

You can get the offset by looking at the EPROCESS structure during driver
initialization for “SYSTEM” or something like that. Then you can get the
base name of the executable which you can match to the full pathname you
saved during the IRP_MJ_CREATE that opened the executable. The process ID
might be useful to prevent confusion. You can then look in the PE header
for dates/times, sizes and image checksums to validate the executable.

Not perfect, but with all the help we get from M$, it is about the best
possible. The changes in XP do help, but they are only a minor part of what
is needed in the security arena.

Peter, from your late posts, you must be teaching on the East Coast again.
I wish more of the people posting questions, especially about file systems
would just take the OSR course(s). Of course, it would be nice if the file
systems class was more than once a year, but I guess you don’t get the
volume you need to have it more often. I remember it took me over a year to
get it and once it was canceled.

----- Original Message -----
From: “Peter Viscarola”
Newsgroups: ntfsd
To: “File Systems Developers”
Sent: Friday, May 03, 2002 7:31 PM
Subject: [ntfsd] Re: Process Name

> “Nicholas Ryan” wrote in message news:xxxxx@ntfsd…
> >
> > Just the base filename of the process or the full
> > pathname? The former you can get using the simple
> > method demonstrated in FileMon, the latter you cannot
> > get without walking through several levels of
> > undocumented internal data structures. Search the
> > mailing list, there are many messages on this topic.
> >
>
> If the “simple method demonstrated by FileMon” is still (I haven’t looked
at
> the code for years) to get the ImageName from some hard-coded offset in
the
> EPROCESS, this is a bad idea. And walking through several layers of
> internal data structures is an even WORSE idea.
>
> Specifically, the offset to the ImageName has (really) changed between O/S
> versions. Who knows, maybe it could change between service packs.
>
> Not to mention the issue that if you get just the ImageName, what does
that
> really tell you? Surely you won’t base a security decision on this?
>
> The way I understand it, presently the only way to do this safely is from
> user mode. There may be a safe kernel-mode facility for doing this in the
> future. I agree that it certainly would be useful.
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to %%email.unsub%%
>

5

I have never understood how anyone can mention ‘process name’ and
‘security’ in the same breath. The NT kernel is not designed to view a
PE file name or process name as the identifier of a security
subject/principal, and so it makes no efforts to guarantee the integrity
of this data.

Anyone can spoof anything in the way of a process or executable name
with a certain amount of effort.

If you are trying to grant access to a particular function in the kernel
only when mediated by a particular piece of code outside the kernel,
then you need to use privileges or something like them. You could, for
example, arrange some sort of cryptographic handshake. A process could
pass a token into the kernel, where it could be stored in association
with a unique id of the process. Or you could require a specific user or
group to be in the token, and run a service as that user that accepts
requests from ordinary folk via, say, shared memory, and then passes the
acceptable ones down to the kernel.

6

Again, it all depends on what you are attempting to
secure against. If you are attempting to secure
against the actions of malicious users, then yes, you
cannot rely on the process name. However, if you’re
simply attempting to guard against accidental misuse
of secure data, the process name is fine as a
heuristic.

— Benson Margulies wrote:
> I have never understood how anyone can mention
> ‘process name’ and
> ‘security’ in the same breath. The NT kernel is not
> designed to view a
> PE file name or process name as the identifier of a
> security
> subject/principal, and so it makes no efforts to
> guarantee the integrity
> of this data.
>
> Anyone can spoof anything in the way of a process or
> executable name
> with a certain amount of effort.
>
> If you are trying to grant access to a particular
> function in the kernel
> only when mediated by a particular piece of code
> outside the kernel,
> then you need to use privileges or something like
> them. You could, for
> example, arrange some sort of cryptographic
> handshake. A process could
> pass a token into the kernel, where it could be
> stored in association
> with a unique id of the process. Or you could
> require a specific user or
> group to be in the token, and run a service as that
> user that accepts
> requests from ordinary folk via, say, shared memory,
> and then passes the
> acceptable ones down to the kernel.
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@nryan.com
> To unsubscribe send a blank email to
%%email.unsub%%

=====
- Nicholas Ryan

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

7

The two do have something in common. I can give you one example of why
people need process name as part of the protection in my AFP module.
Most of the customers make document distribution system, where they need
to allow only Word to read the file, but it mustn’t be able to write the
file. Other applications have no access to the file. This case uses process
names very well, and even though you shouldn’t use it for trusting an
application, it does have another cheek.

Regards, Dejan.

Benson Margulies wrote:

I have never understood how anyone can mention ‘process name’ and
‘security’ in the same breath. The NT kernel is not designed to view a
PE file name or process name as the identifier of a security
subject/principal, and so it makes no efforts to guarantee the integrity
of this data.

Anyone can spoof anything in the way of a process or executable name
with a certain amount of effort.

If you are trying to grant access to a particular function in the kernel
only when mediated by a particular piece of code outside the kernel,
then you need to use privileges or something like them. You could, for
example, arrange some sort of cryptographic handshake. A process could
pass a token into the kernel, where it could be stored in association
with a unique id of the process. Or you could require a specific user or
group to be in the token, and run a service as that user that accepts
requests from ordinary folk via, say, shared memory, and then passes the
acceptable ones down to the kernel.

You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to %%email.unsub%%

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com ICQ#: 56570367
Alfa File Monitor - File monitoring library for Win32 developers.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa Registry Monitor - Registry monitoring library for Win32 developers.
Alfa Registry Protector - Registry protection library for Win32 developers.

8

This is the exact scenario mentioned earlier as to why using the process name is bad. Anyone can create a process called WORD.

For you to claim you have a filter that allows WORD to read the documents but not other applications is no protection since anyone can rename an image file to word.exe, run it, and then read the documents you are trying to protect.

You claim you also have “other” ways to tell it is WORD. If those other ways are legitimate then use them but comparing against process name has absolutely no “security” value whatsoever.

Neal Christiansen
?
This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Saturday, May 04, 2002 03:16 AM
To: File Systems Developers
Subject: [ntfsd] Re: Process Name

The two do have something in common. I can give you one example of why
people need process name as part of the protection in my AFP module.
Most of the customers make document distribution system, where they need
to allow only Word to read the file, but it mustn’t be able to write the
file. Other applications have no access to the file. This case uses process
names very well, and even though you shouldn’t use it for trusting an
application, it does have another cheek.

Regards, Dejan.

Benson Margulies wrote:

I have never understood how anyone can mention ‘process name’ and
‘security’ in the same breath. The NT kernel is not designed to view a
PE file name or process name as the identifier of a security
subject/principal, and so it makes no efforts to guarantee the integrity
of this data.

Anyone can spoof anything in the way of a process or executable name
with a certain amount of effort.

If you are trying to grant access to a particular function in the kernel
only when mediated by a particular piece of code outside the kernel,
then you need to use privileges or something like them. You could, for
example, arrange some sort of cryptographic handshake. A process could
pass a token into the kernel, where it could be stored in association
with a unique id of the process. Or you could require a specific user or
group to be in the token, and run a service as that user that accepts
requests from ordinary folk via, say, shared memory, and then passes the
acceptable ones down to the kernel.

You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to %%email.unsub%%

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com ICQ#: 56570367
Alfa File Monitor - File monitoring library for Win32 developers.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa Registry Monitor - Registry monitoring library for Win32 developers.
Alfa Registry Protector - Registry protection library for Win32 developers.

You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

9

In this scenario, it doesn’t matter. The user can open 100 instances of Word (if that were possible:-), and access the file.
I might not be expressing this correctly, but for this specific case, process based protection is ALL that is needed. Frankly, I think that it does not need by process protection, but they insist, and who am I to argue with a
customer, even if he isn’t a hacker guru:-)

Regards, Dejan.

Neal Christiansen wrote:

This is the exact scenario mentioned earlier as to why using the process name is bad. Anyone can create a process called WORD.

For you to claim you have a filter that allows WORD to read the documents but not other applications is no protection since anyone can rename an image file to word.exe, run it, and then read the documents you are trying to protect.

You claim you also have “other” ways to tell it is WORD. If those other ways are legitimate then use them but comparing against process name has absolutely no “security” value whatsoever.

Neal Christiansen

This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Saturday, May 04, 2002 03:16 AM
To: File Systems Developers
Subject: [ntfsd] Re: Process Name

The two do have something in common. I can give you one example of why
people need process name as part of the protection in my AFP module.
Most of the customers make document distribution system, where they need
to allow only Word to read the file, but it mustn’t be able to write the
file. Other applications have no access to the file. This case uses process
names very well, and even though you shouldn’t use it for trusting an
application, it does have another cheek.

Regards, Dejan.

Benson Margulies wrote:

> I have never understood how anyone can mention ‘process name’ and
> ‘security’ in the same breath. The NT kernel is not designed to view a
> PE file name or process name as the identifier of a security
> subject/principal, and so it makes no efforts to guarantee the integrity
> of this data.
>
> Anyone can spoof anything in the way of a process or executable name
> with a certain amount of effort.
>
> If you are trying to grant access to a particular function in the kernel
> only when mediated by a particular piece of code outside the kernel,
> then you need to use privileges or something like them. You could, for
> example, arrange some sort of cryptographic handshake. A process could
> pass a token into the kernel, where it could be stored in association
> with a unique id of the process. Or you could require a specific user or
> group to be in the token, and run a service as that user that accepts
> requests from ordinary folk via, say, shared memory, and then passes the
> acceptable ones down to the kernel.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to %%email.unsub%%

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com ICQ#: 56570367
Alfa File Monitor - File monitoring library for Win32 developers.
Alfa File Protector - File protection and hiding library for Win32
developers.
Alfa Registry Monitor - Registry monitoring library for Win32 developers.
Alfa Registry Protector - Registry protection library for Win32 developers.

You are currently subscribed to ntfsd as: xxxxx@Windows.Microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to %%email.unsub%%

–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com ICQ#: 56570367
Alfa File Monitor - File monitoring library for Win32 developers.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa Registry Monitor - Registry monitoring library for Win32 developers.
Alfa Registry Protector - Registry protection library for Win32 developers.