RE: reading links in proc - permission denied

RE: reading links in proc - permission denied

[linda w.]

> -----Original Message-----
> From: hurtta@leija.mh.fmi.fi [mailto:hurtta@leija.mh.fmi.fi]
> Are you sure that 'top' uses that 'exe' ?
---
	Not at all...in fact was told it doesn't.  Apparently, though,
the listed permissions on the links are arbitrary and the system
fairly well ignores them.

	I vaguely remember someone once saying that even if a symlink
had permissions lrxw------, it could still be used by group and
others.  I don't know if that was or is still true -- certainly doesn't
seem consistent, but when dealing with computer systems made by
many different humans, inconsistency seems inevitable -- even when
made by 1 human, that person can be inconsistent over time.

	And people wonder why computer security is so hard to 'get right'.

The general attitude is often that 'it is the way that it is, and unless
it is causing a current problem', don't fix it.  In companies -- it
translates to "if it's not a customer reported bug, or performance problem
or feature request", then it's not a priority.  And even when customers
do talk, it depends on the $$$ represented by the customers and the $$$
it will take to fix it.  Cold hard cash.  Perfect capitalistic system
that guarantees security problems won't be fixed until they are
published and/or exploited on enough victims's to add up to $$$'s worth
of business it will cost to fix the bug.

	Even Common Criteria evaluations are run simililarly.  To my knowledge
(and correct me if I am wrong, please! -- http pointers wanted!):

1) there is no requirement for a vendor to report known bugs to
	the third-party evaluation teams or the customers as long as the bug
	is only in internal company databases.

2) Testplans for a product to pass an evaluation as well as the tests
	themselves are created and approved by the third party evaluation
team.
	So, for example:

	a) if you can create a test plan that doesn't test a
	known problem area and the certifier approves the plan, that's
	perfectly legal and going by the system.

	b) if you have to test a problematic area and can create a test that
	avoids the problem, and the Cert. approves the tests as following the
	test plan, that's also legal and going by the system.

	c) if you can't avoid writing a test that will show up the plan, you
	can write the test to be extremely difficult to run and to hide
	the resulting failure -- like requiring a complete system reinstall
	both before and after the test is run.  That way, if a test
	compromises security for later program execution, it won't be
	uncovered since the test plan required an immediate reboot after
	test was run (thus hiding the now compromised system state).  And
again,
	it would appear this is perfectly legal, and following the letter of
	the law as defined by the evaluation system.

3) Only bugs that become publicly known and/or to the end customer need to be
	fixed.

	It seems this is standard practice for the world - accepted CC
security
rating system as I last understood it and as it was last explained to me.

	Now this is for government level security-evaluated systems recognized
in Euro-American (US & Canada) and several other systems.

	The requirements for consumer products, of course, as in the
non-binding click-through license agreement many customers believe in, are
less stringent than the above -- test plan?  What's a test plan -- oh yeah,
that's shipping the product to be tested to 'alpha and beta' sites and see
what turns up.

	Even at the level of formal government security evaluations, there
seem to be loopholes large enough to steer the QE-II through.

	If anyone knows information opposite to the above, please let me know.
	It's pathetic enough now that standard practice with consumer programs
is to ship with little or no testing, then require the consumers to pay
money for each bug they want fixed (via time or (increasingly common) per
incident) fix.

	It's always rubbed me the wrong way to have a company sell me a fault
product, then I have to pay them a 2nd time to fix a bug they put in
the first time.  How do I know that bugs aren't being deliberately planted
to bring in more service revenue -- which can far exceed the cost of the
original product.

-linda

RE: reading links in proc - permission denied

[Ray Olszewski]

I am unclear what purpose the long rant about "[p]erfect capitalistic 
system" handling of software bugs has to do with an operating system and 
applications that most of  get for free, so I'll skip that part.

What governs access to a file is ownership and permissions on the file 
itself, not on symlinks to it (which are customarily lrwxrwxrwx on Linux 
filesystems). This is not mysterious. It's just old-hat Unix.

At 01:55 PM 6/14/2003 -0700, linda w. wrote:


> > -----Original Message-----
> > From: hurtta@leija.mh.fmi.fi [mailto:hurtta@leija.mh.fmi.fi]
> > Are you sure that 'top' uses that 'exe' ?
>---
>         Not at all...in fact was told it doesn't.  Apparently, though,
>the listed permissions on the links are arbitrary and the system
>fairly well ignores them.
>
>         I vaguely remember someone once saying that even if a symlink
>had permissions lrxw------, it could still be used by group and
>others.  I don't know if that was or is still true -- certainly doesn't
>seem consistent, but when dealing with computer systems made by
>many different humans, inconsistency seems inevitable -- even when
>made by 1 human, that person can be inconsistent over time.
>
>         And people wonder why computer security is so hard to 'get right'.
[rest deleted]

Re: reading links in proc - permission denied

[root]

> ---
> 	Not at all...in fact was told it doesn't.  Apparently, though,
> the listed permissions on the links are arbitrary and the system
> fairly well ignores them.
> 
> 	I vaguely remember someone once saying that even if a symlink
> had permissions lrxw------, it could still be used by group and
> others.  I don't know if that was or is still true -- certainly doesn't

man symlink
...
       The permissions of a symbolic  link  are  irrelevant;  the
       ownership  is  ignored  when  following  the  link, but is
       checked when removal or renaming of the link is  requested
       and the link is in a directory with the sticky bit set.

In short, the permissions of the file being linked to are important.

Re: reading links in proc - permission denied

[Albert Cahalan]

> I'm misunderstanding something about links in proc.
>
> I thought 'ps', 'top' et al used /proc to display
> processes, command lines, etc.
>
> Since neither ps nor top are suid root, they are
> running with my uid permissions.
>
> However, if I do "ls -l" on /proc/<number>/exe, I get a
>
> "ls: cannot read symbolic link /proc/16714/exe: Permission denied"
>
> message.

All true, but you're assuming /proc/*/exe is used.
Nope. There is a parser for /proc/*/status and
/proc/*/stat, plus /proc/*/cmdline for args.

Please don't try this yourself. I can spot bugs
in almost any parser for these files. Consider
processes with names like these:

"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
":-) 1 2 3 4 5 6"
"foo Pid: 42"
"x State: Z (z)"

> Now the process is owned by 'named', but the entries in
> diriectory are owned by root (is that right/logical?), thus:

It makes sense in general. An app running on behalf
of a user (with a non-root UID) may still contain
secret data gained via the prior UID.

It would be nice if the app could declare itself
free of this problem.

The restricted permission on /proc/*/exe is kind of
dumb though, considering that /proc/*/maps is wide open.
Ability to follow the link might need to be restricted,
since the link is (was?) magic. It acts somewhat like
a hard link, bypassing permissions along the path.

> Purely from a 'cleanliness' standpoint, is the
> environment owned by the user-id, or is it a common
> piece of public, kernel (root) owned data?

It's swappable. The process can muck with it.

> So why can't I follow the link of 'exe' to see what image the
> process is executing?  Programs like 'ps' and 'top' seem to not
> have this difficulty.

I wish.

> Thanks for any insights...I'm trying to write a simple script
> looking for a running process (by looking at what 'exe' is   
> pointing to).  I would find it kludgey to achieve the objective
> by running 'ps' and doing appropriate filtering. 

There's nothing wrong with parsing ps output. Be sure to split
on whitespace, and not by character position. You can also use
pgrep or pidof. For example:

ps -C foo -opid=
pgrep -u root sshd
pidof something

RE: reading links in proc - permission denied

[linda w.]

Thanks for your answer, I guess not many people understand some of
these things.

So...if I'm not allowed to read the link, wouldn't it be a bug
for the permissions to claim it is group/other readable?

lrwxrwxrwx    1 root     root            0 Jun  5 22:29 /proc/2/exe

Exactly "what" is determining the permissions on the ability to read
the link if not the file permissions?

Should it read?
lrwx------    1 root     root            0 Jun  5 22:29 /proc/2/exe



> Please don't try this yourself. I can spot bugs
> in almost any parser for these files. Consider
> processes with names like these:
>
> "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
> ":-) 1 2 3 4 5 6"
> "foo Pid: 42"
> "x State: Z (z)"
---
	Yeah...it could be a mess, but wouldn't you be guaranteed that it
would be a zero terminated string?

> The restricted permission on /proc/*/exe is kind of
> dumb though, considering that /proc/*/maps is wide open.
> Ability to follow the link might need to be restricted,
> since the link is (was?) magic. It acts somewhat like
> a hard link, bypassing permissions along the path.
---
	Well that "could" be handled by an attempt to stat the target in
the user's context and see if the file can be reached through the
directory chain, but hey, what's the point of consistency, anyway?
"Isn't it consistency is the foolish hobgoblin of small minds?"  Er,
something like that....


>
> > Purely from a 'cleanliness' standpoint, is the
> > environment owned by the user-id, or is it a common
> > piece of public, kernel (root) owned data?
>
> It's swappable. The process can muck with it.
---
	So if the process could muck with it, like path, then if it was
able to switch back to ROOT, wouldn't that be a security risk?

> There's nothing wrong with parsing ps output. Be sure to split
> on whitespace, and not by character position. You can also use
> pgrep or pidof. For example:
>
> ps -C foo -opid=
> pgrep -u root sshd
> pidof something
---
some more primitive unix clones (cygwin for example) don't have
such luxuries....now that I mention it....it doesn't have an 'exe'
entry under proc either...*snort*.

Nevermind....:-)

-l

reading links in proc - permission denied

[linda w.]

I'm misunderstanding something about links in proc. 

I thought 'ps', 'top' et al used /proc to display processes, command lines, etc.

Since neither ps nor top are suid root, they are running with my uid 
permissions.

However, if I do "ls -l" on /proc/<number>/exe, I get a

"ls: cannot read symbolic link /proc/16714/exe: Permission denied"

message.

Now the process is owned by 'named', but the entries in diriectory are 
owned by root (is that right/logical?), thus:

# ll /proc/16714 
total 0
dr-xr-xr-x    3 named    named           0 Jun  4 11:39 ./
dr-xr-xr-x   95 root     root            0 May 30 15:38 ../
-r--r--r--    1 root     root            0 Jun  4 11:39 cmdline
-r--r--r--    1 root     root            0 Jun  4 11:39 cpu
lrwxrwxrwx    1 root     root            0 Jun  4 11:39 cwd -> /var/named/
-r--------    1 root     root            0 Jun  4 11:39 environ
lrwxrwxrwx    1 root     root            0 Jun  4 11:39 exe -> /usr/sbin/named*
dr-x------    2 root     root            0 Jun  4 11:39 fd/
-r--r--r--    1 root     root            0 Jun  4 11:39 maps
-rw-------    1 root     root            0 Jun  4 11:39 mem
-r--r--r--    1 root     root            0 Jun  4 11:39 mounts
lrwxrwxrwx    1 root     root            0 Jun  4 11:39 root -> //
-r--r--r--    1 root     root            0 Jun  4 11:39 stat
-r--r--r--    1 root     root            0 Jun  4 11:39 statm
-r--r--r--    1 root     root            0 Jun  4 11:39 status
---
	Purely from a 'cleanliness' standpoint, is the environment owned by
the user-id, or is it a common piece of public, kernel (root) owned data?

	From observation of other /proc entries, it appears that 'named' has
some unique features in that it is started as root, but then reverts to uid/gid named sometime after startup.  Should some (or all) of the UID's
in proc change ownership to the new UID or are they still considered to
be owned by the old UID?  (Would seem a bit inconsistent -- I wonder if
it could be security exploitable? -- like if a user process was able to
setuid root, would  anything be left in the environment owned by the
original unpriviledged user that could be changed from another running
process, changing things like PATH for the currently running root
process....naw...I'm sure that's plugged...and it's only inconsistent
with root doing setuid to non-root....hmmmm :-/).



	But, here's the part that is bugging me.  Running as user 'foo',
I can't read that link -- yet the permissions say rxw for group and other.
So why am I getting the *permission error*?  The binary it is pointing to
/usr/sbin/named is also publicly readable, so that can't be the problem.

	So why can't I follow the link of 'exe' to see what image the process
is executing?  Programs like 'ps' and 'top' seem to not have this
difficulty.

	I'm sure it's some silly misconfiguration on my part, but I guess I want
to know how I got here.  This isn't my beautiful kernel, it's not my beautiful /proc...(etc...).

	I'm running a xfs-patched kernel, V2.4.20/SMP.

Thanks for any insights...I'm trying to write a simple script looking for
a running process (by looking at what 'exe' is pointing to).  I would 
find it kludgey to achieve the objective by running 'ps' and doing 
appropriate filtering. 

-linda
     

reading links in proc - permission denied

[linda w.]

I'm misunderstanding something about links in proc. 

I thought 'ps', 'top' et al used /proc to display processes, command lines, etc.

Since neither ps nor top are suid root, they are running with my permissions.

However, if I try to do an ls -l on /proc/<number>/exe, I get a

"ls: cannot read symbolic link /proc/16714/exe: Permission denied"

message.

Now the process is owned by 'named', but the entries in diriectory are 
owned by root (is that right?), thus:

# ll /proc/16714 
total 0
dr-xr-xr-x    3 named    named           0 Jun  4 11:39 ./
dr-xr-xr-x   95 root     root            0 May 30 15:38 ../
-r--r--r--    1 root     root            0 Jun  4 11:39 cmdline
-r--r--r--    1 root     root            0 Jun  4 11:39 cpu
lrwxrwxrwx    1 root     root            0 Jun  4 11:39 cwd -> /var/named/
-r--------    1 root     root            0 Jun  4 11:39 environ
lrwxrwxrwx    1 root     root            0 Jun  4 11:39 exe -> /usr/sbin/named*
dr-x------    2 root     root            0 Jun  4 11:39 fd/
-r--r--r--    1 root     root            0 Jun  4 11:39 maps
-rw-------    1 root     root            0 Jun  4 11:39 mem
-r--r--r--    1 root     root            0 Jun  4 11:39 mounts
lrwxrwxrwx    1 root     root            0 Jun  4 11:39 root -> //
-r--r--r--    1 root     root            0 Jun  4 11:39 stat
-r--r--r--    1 root     root            0 Jun  4 11:39 statm
-r--r--r--    1 root     root            0 Jun  4 11:39 status
---
	Purely from a 'cleanliness' standpoint, is the environment owned by
the user-id, or is it a common piece of public, kernel (root) owned data?

	From observation of other /proc entries, it appears that 'named' has
some unique features in that it is started as root, but then reverts to uid/gid named sometime after startup.  Should some (or all) of the UID's
in proc change ownership to the new UID or are they still considered to
be owned by the old UID?  (Would seem a bit inconsistent -- I wonder if
it could be security exploitable?)

	Now, here's the part that is bugging me.  Running as user 'foo',
I can't read that link -- yet the permissions say rxw for group and other.
So why am I getting the permission error?  The binary it is pointing to
/usr/sbin/named is also publicly readable, so that can't be the problem.

	So why can't I follow the link of 'exe' to see what image the process
is executing while programs like 'ps' and 'top' seem to not have this
difficulty?

	I'm sure it's some silly misconfiguration on my part, but I guess I want
to know how I got here.  This isn't my beautiful kernel, it's not my beautiful /proc...(etc...).

	I'm running a xfs-patched kernel, V2.4.20/SMP.

Thanks for any insights...I'm trying to write a simple script looking for
a running process (by looking at what 'exe' is pointing to).  I would 
find it kludgey to achieve the objective by running 'ps' and doing 
appropriate filtering. 

-linda