Lorenzo Hernandez Garcia-Hierro lorenzohgh at gmail.com
Tue Nov 1 18:04:45 CST 2005


El mar, 01-11-2005 a las 17:56 -0400, jeff.schroeder2 at us.army.mil
escribió:
> Ok, sounds good.

Certainly does :).

> In ubuntu, users in the "admin" group are effectively
> root through sudo. Should the admin group be given
> access to capabilities such as, "CAP_SYS_ADMIN",
> "CAP_SYS_CHROOT", "CAP_SYS_NICE", "CAP_NET_ADMIN",
> etc through cap_over? More info in available in the
> capabilities(7) man page.

Well, that's a dilemma:

	1) fine-grained capabilities: not given on a
	   per-group basis, but per-binary basis

	advantages:

		- it's fine-grained anyways
		- binaries get capabilities they need
		  to work, and nothing more
		- portable and usable for *any* distro.
	shortcomings:
		- doesn't take advantage of currently
		  established user groups, used by the
		  packages in Debian and Ubuntu Linux.

	2) per-group capabilities:

	advantages:

		- we use Debian/Ubuntu Linux user groups
		  which are used by each package (ie. cups, etc).
		- simple.
	shortcomings:

		- not fine-grained: we grant capabilities that
		  aren't needed.
		- dangerous: more prone to mistakes made by the
		  user (ie. adds XYZ application to FOO and BAR
		  groups with certain capabilities granted which
		  open a flaw).
		- not portable. Fedora Core or other distros may handle
		  such user groups separately.

I want to develop a profile-based policy manager, that can handle
separate policy files and users specifications. Maybe profiles could
define different scenarios for each distribution.

That would cover both (1) and (2) without adding further difficulties.
If not, then we must fall through (1). Personally, I think (1) is the
way to go if we want to keep control over the policy enforcement.

> If the answer is yes to any of those, what groups
> should get what priviliges by default?

Needs further study. But a start point would be to check capabilities
that the applications need in each group.

> Normal users (if any) vs administrators? If the apache
> group is given the "CAP_NET_BIND_SERVICE" capability
> which allows it to bind to ports <1024, could apache
> be sucessfully de-rooted? These are all things we
> should be thinking of.

Right ;).

Maybe we could try to develop a wrapper for strace to check what
capabilities are "requested". Or work on a learning mode for vSecurity,
pretty much like grsecurity's one. The point is that we need to generate
least privilege policies. We'll see.

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo at gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : http://lists.ubuntu.com/archives/ubuntu-hardened/attachments/20051102/52c8ff63/attachment.pgp


More information about the ubuntu-hardened mailing list