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
> 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
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
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> 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
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: [email protected] [mailto:[email protected]]
> > 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]
> ---
> 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.