linux-kernel - Re: RFC: Network privilege separation.

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: <20090108104305.7b271053@lxorguk.ukuu.org.uk>
Date:	Thu, 8 Jan 2009 10:43:05 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Michael Stone <michael@...top.org>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: RFC: Network privilege separation.

> Conclusion: so far as I can see, RLIMIT_NETWORK is, in every way, a smaller
> expansion of the end user's trusted code base and should therefore be preferred
> in comparison netfilter-based solutions for process-level network privilege
> separation tasks. Do you see things differently?

If you have the same uid then you can just use ptrace to drive another
task with that uid to do the creations for you. Chances are you can also
attack shared executable files (eg that uids .bashrc)

That to me says controlling network access is only useful as part of a
more fine grained and general purpose interface. We already have that
interface in the form of things like SELinux. We already have systems
actively using it to control stuff like which ports are accessed by some
services.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/