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]

Date:	Fri, 4 Jul 2014 12:53:19 -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 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.

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