ls -l /proc/1/exe -> Permission denied

ls -l /proc/1/exe -> Permission denied

[Joakim Tjernlund]

Trying to real /proc/<pid>/exe I noticed I could not read links not 
belonging to my user such as:
jocke >  ls -l /proc/1/exe
             ls: cannot read symbolic link /proc/1/exe: Permission denied

Is this expected?

uname -a
Linux gentoo-jocke 3.12.21

Re: ls -l /proc/1/exe -> Permission denied

[Richard Weinberger]

On Thu, Jul 17, 2014 at 1:18 PM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
> Trying to real /proc/<pid>/exe I noticed I could not read links not
> belonging to my user such as:
> jocke >  ls -l /proc/1/exe
>              ls: cannot read symbolic link /proc/1/exe: Permission denied
>
> Is this expected?

Why do you think this is unexpected?

-- 
Thanks,
//richard

Re: ls -l /proc/1/exe -> Permission denied

[Joakim Tjernlund]

Richard Weinberger <richard.weinberger@gmail.com> wrote on 2014/07/18 
14:58:30:
> 
> On Thu, Jul 17, 2014 at 1:18 PM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> > Trying to real /proc/<pid>/exe I noticed I could not read links not
> > belonging to my user such as:
> > jocke >  ls -l /proc/1/exe
> >              ls: cannot read symbolic link /proc/1/exe: Permission 
denied
> >
> > Is this expected?
> 
> Why do you think this is unexpected?

It only shows the full path to the executable, compare with comm which 
shows basename(app).

I have an idea for qemu-user which needs to identify which processes
are running /usr/bin/qemu-<arch> and which are not so it knows how
to munge different /proc/ files.

 Jocke

Re: ls -l /proc/1/exe -> Permission denied

[Joakim Tjernlund]

Joakim Tjernlund/Transmode wrote on 2014/07/18 15:49:17:
> 
> Richard Weinberger <richard.weinberger@gmail.com> wrote on 2014/07/18 
14:58:30:
> > 
> > On Thu, Jul 17, 2014 at 1:18 PM, Joakim Tjernlund
> > <joakim.tjernlund@transmode.se> wrote:
> > > Trying to real /proc/<pid>/exe I noticed I could not read links not
> > > belonging to my user such as:
> > > jocke >  ls -l /proc/1/exe
> > >              ls: cannot read symbolic link /proc/1/exe: Permission 
denied
> > >
> > > Is this expected?
> > 
> > Why do you think this is unexpected?

> It only shows the full path to the executable, compare with comm which 
shows basename(app).
> 
> I have an idea for qemu-user which needs to identify which processes
> are running /usr/bin/qemu-<arch> and which are not so it knows how
> to munge different /proc/ files.

Just to be clear, I expect to read where /proc/1/exe points, not the 
contents of the file
pointed to.

It seems that any and all symlinks are forbidden:
> ls -l /proc/1
ls: cannot read symbolic link /proc/1/cwd: Permission denied
ls: cannot read symbolic link /proc/1/root: Permission denied
ls: cannot read symbolic link /proc/1/exe: Permission denied

 Jocke

Re: ls -l /proc/1/exe -> Permission denied

[Richard Weinberger]

Am 18.07.2014 17:05, schrieb Joakim Tjernlund:
> Joakim Tjernlund/Transmode wrote on 2014/07/18 15:49:17:
>>
>> Richard Weinberger <richard.weinberger@gmail.com> wrote on 2014/07/18 
> 14:58:30:
>>>
>>> On Thu, Jul 17, 2014 at 1:18 PM, Joakim Tjernlund
>>> <joakim.tjernlund@transmode.se> wrote:
>>>> Trying to real /proc/<pid>/exe I noticed I could not read links not
>>>> belonging to my user such as:
>>>> jocke >  ls -l /proc/1/exe
>>>>              ls: cannot read symbolic link /proc/1/exe: Permission 
> denied
>>>>
>>>> Is this expected?
>>>
>>> Why do you think this is unexpected?
> 
>> It only shows the full path to the executable, compare with comm which 
> shows basename(app).
>>
>> I have an idea for qemu-user which needs to identify which processes
>> are running /usr/bin/qemu-<arch> and which are not so it knows how
>> to munge different /proc/ files.
> 
> Just to be clear, I expect to read where /proc/1/exe points, not the 
> contents of the file
> pointed to.
> 
> It seems that any and all symlinks are forbidden:
>> ls -l /proc/1
> ls: cannot read symbolic link /proc/1/cwd: Permission denied
> ls: cannot read symbolic link /proc/1/root: Permission denied
> ls: cannot read symbolic link /proc/1/exe: Permission denied

Because they all share the same implementation.
See proc_pid_link_inode_operations() in fs/proc/base.c

Happy hacking. :-)

Thanks,
//richard

Re: ls -l /proc/1/exe -> Permission denied

[Andreas Schwab]

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

> Trying to real /proc/<pid>/exe I noticed I could not read links not 
> belonging to my user such as:
> jocke >  ls -l /proc/1/exe
>              ls: cannot read symbolic link /proc/1/exe: Permission denied
>
> Is this expected?

Yes.  This information is considered private.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ls -l /proc/1/exe -> Permission denied

[Joakim Tjernlund]

Andreas Schwab <schwab@linux-m68k.org> wrote on 2014/07/19 22:21:59:
> 
> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
> 
> > Trying to real /proc/<pid>/exe I noticed I could not read links not 
> > belonging to my user such as:
> > jocke >  ls -l /proc/1/exe
> >              ls: cannot read symbolic link /proc/1/exe: Permission 
denied
> >
> > Is this expected?
> 
> Yes.  This information is considered private.

I don't understand why though.
Why have exe in the fist place then?

 Jocke

Re: ls -l /proc/1/exe -> Permission denied

[Andreas Schwab]

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

> Andreas Schwab <schwab@linux-m68k.org> wrote on 2014/07/19 22:21:59:
>> 
>> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>> 
>> > Trying to real /proc/<pid>/exe I noticed I could not read links not 
>> > belonging to my user such as:
>> > jocke >  ls -l /proc/1/exe
>> >              ls: cannot read symbolic link /proc/1/exe: Permission 
> denied
>> >
>> > Is this expected?
>> 
>> Yes.  This information is considered private.
>
> I don't understand why though.

It would allow bypassing access restrictions.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ls -l /proc/1/exe -> Permission denied

[Richard Weinberger]

On Sun, Jul 20, 2014 at 12:55 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>
>> Andreas Schwab <schwab@linux-m68k.org> wrote on 2014/07/19 22:21:59:
>>>
>>> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>>>
>>> > Trying to real /proc/<pid>/exe I noticed I could not read links not
>>> > belonging to my user such as:
>>> > jocke >  ls -l /proc/1/exe
>>> >              ls: cannot read symbolic link /proc/1/exe: Permission
>> denied
>>> >
>>> > Is this expected?
>>>
>>> Yes.  This information is considered private.
>>
>> I don't understand why though.
>
> It would allow bypassing access restrictions.

Do you have an example?
I'm asking because an attacker could make any symlink as he wants to.
A ln -s /etc/shadow lala still does not give me access to shadow...

-- 
Thanks,
//richard

Re: ls -l /proc/1/exe -> Permission denied

[Joakim Tjernlund]

Richard Weinberger <richard.weinberger@gmail.com> wrote on 2014/07/20 
13:06:30:
> 
> On Sun, Jul 20, 2014 at 12:55 PM, Andreas Schwab <schwab@linux-m68k.org> 
wrote:
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
> >
> >> Andreas Schwab <schwab@linux-m68k.org> wrote on 2014/07/19 22:21:59:
> >>>
> >>> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
> >>>
> >>> > Trying to real /proc/<pid>/exe I noticed I could not read links 
not
> >>> > belonging to my user such as:
> >>> > jocke >  ls -l /proc/1/exe
> >>> >              ls: cannot read symbolic link /proc/1/exe: Permission
> >> denied
> >>> >
> >>> > Is this expected?
> >>>
> >>> Yes.  This information is considered private.
> >>
> >> I don't understand why though.
> >
> > It would allow bypassing access restrictions.
> 
> Do you have an example?
> I'm asking because an attacker could make any symlink as he wants to.
> A ln -s /etc/shadow lala still does not give me access to shadow...

precisely, I just want to see what it is pointing too.
Also, the links privs are inconsistent with current behaviour:
 lrwxrwxrwx   1 root root 0 Jul 15 19:03 exe

 Jocke

Re: ls -l /proc/1/exe -> Permission denied

[Andreas Schwab]

Richard Weinberger <richard.weinberger@gmail.com> writes:

> On Sun, Jul 20, 2014 at 12:55 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>>
>>> Andreas Schwab <schwab@linux-m68k.org> wrote on 2014/07/19 22:21:59:
>>>>
>>>> Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:
>>>>
>>>> > Trying to real /proc/<pid>/exe I noticed I could not read links not
>>>> > belonging to my user such as:
>>>> > jocke >  ls -l /proc/1/exe
>>>> >              ls: cannot read symbolic link /proc/1/exe: Permission
>>> denied
>>>> >
>>>> > Is this expected?
>>>>
>>>> Yes.  This information is considered private.
>>>
>>> I don't understand why though.
>>
>> It would allow bypassing access restrictions.
>
> Do you have an example?

proc symlinks are special because they actually resolve to the inode.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ls -l /proc/1/exe -> Permission denied

[Richard Weinberger]

Am 20.07.2014 13:51, schrieb Andreas Schwab:
> Richard Weinberger <richard.weinberger@gmail.com> writes:
>> Do you have an example?
> 
> proc symlinks are special because they actually resolve to the inode.

Ah. If an attacker manages the kernel to follow the symlink he could
indirectly access that file.
Thanks for pointing this out!

Thanks,
//richard

Re: ls -l /proc/1/exe -> Permission denied

[Richard Weinberger]

Am 20.07.2014 13:51, schrieb Andreas Schwab:
> Richard Weinberger <richard.weinberger@gmail.com> writes:
>> Do you have an example?
> 
> proc symlinks are special because they actually resolve to the inode.

Ah. If an attacker manages the kernel to follow the symlink he could
indirectly access that file.
Thanks for pointing this out!

Thanks,
//richard

Re: ls -l /proc/1/exe -> Permission denied

[Joakim Tjernlund]

Richard Weinberger <richard@nod.at> wrote on 2014/07/20 14:05:41:
> 
> Am 20.07.2014 13:51, schrieb Andreas Schwab:
> > Richard Weinberger <richard.weinberger@gmail.com> writes:
> >> Do you have an example?
> > 
> > proc symlinks are special because they actually resolve to the inode.
> 
> Ah. If an attacker manages the kernel to follow the symlink he could
> indirectly access that file.
> Thanks for pointing this out!

That is a big if, I read this as you don't trust the kernels impl.
of proc sym links so paper over this with denying all other to read 
trivial
data such as the exe sym link.

 Jocke 

Re: ls -l /proc/1/exe -> Permission denied

[Richard Weinberger]

Am 20.07.2014 21:15, schrieb Joakim Tjernlund:
> Richard Weinberger <richard@nod.at> wrote on 2014/07/20 14:05:41:
>>
>> Am 20.07.2014 13:51, schrieb Andreas Schwab:
>>> Richard Weinberger <richard.weinberger@gmail.com> writes:
>>>> Do you have an example?
>>>
>>> proc symlinks are special because they actually resolve to the inode.
>>
>> Ah. If an attacker manages the kernel to follow the symlink he could
>> indirectly access that file.
>> Thanks for pointing this out!
> 
> That is a big if, I read this as you don't trust the kernels impl.
> of proc sym links so paper over this with denying all other to read 
> trivial
> data such as the exe sym link.

Feel free to propose a solution for that. :-)

Thanks,
//richard

Re: ls -l /proc/1/exe -> Permission denied

[Joakim Tjernlund]

Richard Weinberger <richard@nod.at> wrote on 2014/07/20 22:00:02:
> 
> Am 20.07.2014 21:15, schrieb Joakim Tjernlund:
> > Richard Weinberger <richard@nod.at> wrote on 2014/07/20 14:05:41:
> >>
> >> Am 20.07.2014 13:51, schrieb Andreas Schwab:
> >>> Richard Weinberger <richard.weinberger@gmail.com> writes:
> >>>> Do you have an example?
> >>>
> >>> proc symlinks are special because they actually resolve to the 
inode.
> >>
> >> Ah. If an attacker manages the kernel to follow the symlink he could
> >> indirectly access that file.
> >> Thanks for pointing this out!
> > 
> > That is a big if, I read this as you don't trust the kernels impl.
> > of proc sym links so paper over this with denying all other to read 
> > trivial
> > data such as the exe sym link.
> 
> Feel free to propose a solution for that. :-)

I wish I had one :) Good to know why things are how they are though. I
guess there is a reason why proc symlinks resolve to the inode?

 Jocke

Re: ls -l /proc/1/exe -> Permission denied

[Richard Weinberger]

Am 20.07.2014 13:51, schrieb Andreas Schwab:
> Richard Weinberger <richard.weinberger@gmail.com> writes:
>> Do you have an example?
> 
> proc symlinks are special because they actually resolve to the inode.

Ah. If an attacker manages the kernel to follow the symlink he could
indirectly access that file.
Thanks for pointing this out!

Thanks,
//richard

Re: ls -l /proc/1/exe -> Permission denied

[Eric W. Biederman]

Richard Weinberger <richard@nod.at> writes:

> Am 20.07.2014 13:51, schrieb Andreas Schwab:
>> Richard Weinberger <richard.weinberger@gmail.com> writes:
>>> Do you have an example?
>> 
>> proc symlinks are special because they actually resolve to the inode.
>
> Ah. If an attacker manages the kernel to follow the symlink he could
> indirectly access that file.
> Thanks for pointing this out!

We only allow this access for processes that we are allowed to ptrace
because knowing intimate details of a process such as which files it has
open and in this case which file it is executing can make it more
attackable. (Say by looking to see if a processes is still running some
old vulnerable version and hasn't been restarted yet).

Normally this only applies to processes owned by different users.

However some configurations restrict ptrace on processes that you own.
You will have to look at the ``security'' modules you have enabled
and configured to see what that policy is, to see why you aren't allowed
to access your own processes.

Eric