Date:	Mon, 14 Jul 2014 10:05:44 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
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

On Mon, Jul 14, 2014 at 9:43 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@...sung.com> wrote:
>
> 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.

This is, for better or for worse, not true.  I think that essentially
every setuid program on my system allows some degree of control over
what goes to stdout.  Many of them allow nearly complete control.

>
> 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).

What about the existing programs that *don't* want to send this information?

>
> 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).

Having gone through this a couple times with existing security issues,
I guarantee that Linus will disagree with this sentiment.  These
setuid programs are the majority, and I would argue that they aren't
buggy.

--Andy
--
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

Powered by blists - more mailing lists