Hi Michal,

On 21 December 2017 at 09:02, Michal Hocko [off-list ref] wrote:

On Wed 20-12-17 17:17:46, Michael Kerrisk wrote:

quoted

Hello Michal,

On 20 December 2017 at 10:20, Michal Hocko [off-list ref] wrote:

quoted

On Tue 19-12-17 17:45:40, Michael Kerrisk wrote:

quoted

But, is
there a pressing reason to make the change? (Okay, I guess iterating
using *_STAT is nicer than parsing /proc/sysvipc/*.)

The reporter of this issue claims that "Reading /proc/sysvipc/shm is way
slower than executing the system call." I haven't checked that but I can
imagine that /proc/sysvipc/shm can take quite some time when there are
_many_ segments registered.

Yes, that makes sense.

quoted

So they would like to use the syscall but
the interacting parties do not have compatible permissions.

So, I don't think there is any security issue, since the same info is
available in /proc/sysvipc/*.

Well, I am not sure this is a valid argument (maybe I just misread your
statement).

(Or perhaps I was not clear enough; see below)

Our security model _might_ be broken because of the sysipc
proc interface existance already. I am not saying it is broken because
I cannot see an attack vector based solely on the metadata information
knowledge. An attacker still cannot see/modify the real data. But maybe
there are some bugs lurking there and knowing the metadata might help to
exploit them. I dunno.

You are certainly right that modifying/adding STAT flag to comply with
the proc interface permission model will not make the system any more
vulnerable, though.

Yep, that was my point. Modifying _STAT behavior won't decrease security.

That said, /proc/sysvipc/* has been around for a long time now, and
nothing bad seems to have happened so far, AFAIK.

quoted

The only question would be whether
change in the *_STAT behavior might surprise some applications into
behaving differently. I presume the chances of that are low, but if it
was a concert, one could add new shmctl/msgctl/semctl *_STAT_ALL (or
some such) operations that have the desired behavior.

I would lean towards _STAT_ALL because this is Linux specific behavior
(I have looked at what BSD does here and they are checking permissions
for STAT as well). It would also be simpler to revert if we ever find
that this is a leak with security consequences.

Oh -- I was unaware of this BSD behavior. At least on the various UNIX
systems that I ever used SYSVIPC (including one or two ancient
commercial BSD derivatives), ipcs(1) showed all IPC objects. (On
FeeBSD, at least, it looks like ipcs(1) doesn't use the *_STAT
interfaces.)

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/