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
On Thu, Jul 17, 2014 at 1:18 PM, Joakim Tjernlund
<[email protected]> 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
Richard Weinberger <[email protected]> wrote on 2014/07/18
14:58:30:
>
> On Thu, Jul 17, 2014 at 1:18 PM, Joakim Tjernlund
> <[email protected]> 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
Joakim Tjernlund <[email protected]> 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, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab <[email protected]> wrote on 2014/07/19 22:21:59:
>
> Joakim Tjernlund <[email protected]> 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
Joakim Tjernlund <[email protected]> writes:
> Andreas Schwab <[email protected]> wrote on 2014/07/19 22:21:59:
>>
>> Joakim Tjernlund <[email protected]> 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, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sun, Jul 20, 2014 at 12:55 PM, Andreas Schwab <[email protected]> wrote:
> Joakim Tjernlund <[email protected]> writes:
>
>> Andreas Schwab <[email protected]> wrote on 2014/07/19 22:21:59:
>>>
>>> Joakim Tjernlund <[email protected]> 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
Richard Weinberger <[email protected]> wrote on 2014/07/20
13:06:30:
>
> On Sun, Jul 20, 2014 at 12:55 PM, Andreas Schwab <[email protected]>
wrote:
> > Joakim Tjernlund <[email protected]> writes:
> >
> >> Andreas Schwab <[email protected]> wrote on 2014/07/19 22:21:59:
> >>>
> >>> Joakim Tjernlund <[email protected]> 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
Richard Weinberger <[email protected]> writes:
> On Sun, Jul 20, 2014 at 12:55 PM, Andreas Schwab <[email protected]> wrote:
>> Joakim Tjernlund <[email protected]> writes:
>>
>>> Andreas Schwab <[email protected]> wrote on 2014/07/19 22:21:59:
>>>>
>>>> Joakim Tjernlund <[email protected]> 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, [email protected]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Am 20.07.2014 13:51, schrieb Andreas Schwab:
> Richard Weinberger <[email protected]> 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
Am 20.07.2014 13:51, schrieb Andreas Schwab:
> Richard Weinberger <[email protected]> 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
Am 20.07.2014 13:51, schrieb Andreas Schwab:
> Richard Weinberger <[email protected]> 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
Richard Weinberger <[email protected]> wrote on 2014/07/20 14:05:41:
>
> Am 20.07.2014 13:51, schrieb Andreas Schwab:
> > Richard Weinberger <[email protected]> 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
Am 20.07.2014 21:15, schrieb Joakim Tjernlund:
> Richard Weinberger <[email protected]> wrote on 2014/07/20 14:05:41:
>>
>> Am 20.07.2014 13:51, schrieb Andreas Schwab:
>>> Richard Weinberger <[email protected]> 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
Richard Weinberger <[email protected]> wrote on 2014/07/20 22:00:02:
>
> Am 20.07.2014 21:15, schrieb Joakim Tjernlund:
> > Richard Weinberger <[email protected]> wrote on 2014/07/20 14:05:41:
> >>
> >> Am 20.07.2014 13:51, schrieb Andreas Schwab:
> >>> Richard Weinberger <[email protected]> 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
Richard Weinberger <[email protected]> writes:
> Am 20.07.2014 13:51, schrieb Andreas Schwab:
>> Richard Weinberger <[email protected]> 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