netdev - Re: [PATCH net-next V2 0/2] send process status in SCM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <4754290.xkOB1pnWlf@amdc1032>
Date:	Mon, 14 Jul 2014 18:43:48 +0200
From:	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Piotr Wilczek <p.wilczek@...sung.com>,
	David Miller <davem@...emloft.net>,
	Network Development <netdev@...r.kernel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	juho80.son@...sung.com, jkaluza@...hat.com
Subject: Re: [PATCH net-next V2 0/2] send process status in SCM_PROCINFO


Hi,

On Friday, July 04, 2014 12:53:19 PM Andy Lutomirski wrote:
> On Fri, Jul 4, 2014 at 10:58 AM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@...sung.com> wrote:
> > On Friday, July 04, 2014 10:07:24 AM Andy Lutomirski wrote:
> >> > Then why this should be a problem?  All information obtained through
> >> > SCM_PROCINFO comes from the kernel not the application itself.
> >>
> >> So what?  The information is correct in the sense of correctly
> >> identifying who called write(2).  The problem is that any code (user
> >> or kernel) that thinks it cares who called write(2) is *wrong*.  Full
> >> stop.  That code cares about who intended the message to be send,
> >> which may or not be the same entity that called write(2).
> >
> > Do you mean that the process doing write(2) can be different from the one
> > intending it?  How is that a problem in our case?  We only care about info
> > about entity that actually called write(2).  We completely don't care about
> > the intent in the kernel and any code doing any authorization based on
> > the obtained information in user-space would be seriously wrong because
> > the information is stale once it leaves kernel and has only historic value.
> > Am I missing something?
> 
> What exactly is your case?  If it's purely for debugging, fine.  But
> if it's a log and anyone ever wants to think of it as a reliable audit
> log, this isn't so good.  For example, if I see a log message from
> _UID=0 saying something important, I am likely to believe that
> something privileged actually generated that text.  This *cannot* be
> guaranteed by SCM_CREDENTIALS on a datagram socket.

It would be the best to give some _solid_ examples of how SCM_PROCINFO
interface can allow additional security issues that are currently not
a problem with procfs approach.  If the setuid application having _UID=0
allows to pass arbitrary messages to stdout it is buggy and needs fixing
already.

I see that with your proposed scheme you would need to explicitly send
the extra information from the application side which would be indeed
more secure from point of view of buggy setuid applications but it will
punish every normal application by having to update its code and getting
lower performance (than with SCM_PROCINFO approach).

Given all this I think that it would be probably much more efficient to
just audit and fix buggy setuid applications instead of converting all
normal applications to the proposed interface (it is probably orders of
magnitude more normal applications using systemd journald than setuid
ones).

Also, Piotr will explain more our (or rather systemd's) use case.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html