El mar, 01-11-2005 a las 17:56 -0400, jeff.schroeder2@xxxxxxxxxxx
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@xxxxxxx>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
|
