netdev - Re: [PATCH v2 net-next] af_unix: dont send 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: <1316492170.2455.43.camel@edumazet-laptop>
Date:	Tue, 20 Sep 2011 06:16:10 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Valdis.Kletnieks@...edu
Cc:	Tim Chen <tim.c.chen@...ux.intel.com>,
	David Miller <davem@...emloft.net>, zheng.z.yan@...el.com,
	yanzheng@...n.com, netdev@...r.kernel.org, sfr@...b.auug.org.au,
	jirislaby@...il.com, sedat.dilek@...il.com, alex.shi@...el.com
Subject: Re: [PATCH v2 net-next] af_unix: dont send SCM_CREDENTIALS by
 default

Le lundi 19 septembre 2011 à 22:10 -0400, Valdis.Kletnieks@...edu a
écrit :
> On Mon, 19 Sep 2011 14:39:58 PDT, Tim Chen said:
> > Do we have to worry about the case where peer socket changes its flag
> > to SOCK_PASSCRED while packets are in flight?  If there isn't such
> > pathological use case, the patch looks fine to me.
> 
> I wouldn't think so - if you're sending a packet, and retroactively trying to
> change the flag and expect it to work, your program is too ugly to live.  After
> all, if the scheduler had cut off your timeslice and scheduledthe receiving
> process before you set the flag, that packet would be delivered and done with
> anyhow, and no amount of wishing will set that flag on an already-delivered
> packet.
> 
> What *is* worth checking is that we DTRT if a process/thread is doing a send on
> one CPU, and another process/thread with a shared file descriptor for that
> socket is diddling the flag.  But if we just define it as "atomic op to change
> the flag and other observers get whatever value their CPU sees at that
> instant", I'm OK with that too.. ;)
> 

Note : The man page does states :

"To receive a struct ucred message the SO_PASSCRED option  must  be
enabled  on  the socket."

But it doesnt say if the SO_PASSCRED option must be enabled before the
sender sends its message, or before receiver attempts to read it.

Once a message is queued on an unix socket, flipping SO_PASSCRED cant
change its content (adding or removing credentials), since sender might
already have disappeared.

So current code includes credentials in all sent messages, just in case
receiver actually fetch credentials.

There are probably programs that assume they can set SO_PASSCRED right
before calling recvmsg(). Are we taking risk to break them, or are we
gentle and provide a sysctl option to ease the transition, I dont
know...



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