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: <CAHo-OozcFULbDBHoWsQPoun-HAaHLBM=pRzMJjsv1cJF77zSYg@mail.gmail.com>
Date:	Fri, 23 Sep 2011 12:33:43 -0700
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	netdev@...r.kernel.org, linux-security-module@...r.kernel.org,
	James Morris <jmorris@...ei.org>
Subject: Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT

> Under what circumstances would a process that requires the
> new capability not require CAP_NET_ADMIN? Is there a real
> case where a process would be expected to require only this
> new capability? Adding new capability values is somewhat
> perilous and the granularity you are proposing, that of
> controlling a single bit, would explode the list of
> capabilities into the hundreds if it were applied throughout
> the kernel.

CAP_NET_ADMIN is a huge hammer, it allows one to totally
reconfigure the networking subsystem.

In a containerized multi-user/job environment, you do not want
something like an instance of a load-balanced web server, proxy
or dns server being able to do that - policy/configuration decisions
should be left up to the administrator and/or machine management
daemon(s).  Each of these can make use of transparent sockets
(in various ways, mostly in coordination with large scale load balancing).

You also do not want one user running in one container being able
to sniff (CAP_NET_RAW) traffic from another user (hence CAP_NET_RAW
isn't an acceptable substitute).

One could conceivably use network namespaces for seperation, but
in this particular case they are _way_ too overkill (and also add too
much overhead).

This might be *just* a single bit in the socket, but this bit effectively
controls whether you can do certain types of privileged operations
on the socket in question - and it gets tested in various places throughout
the networking stack.

Hopefully, this answers your question.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ