Re: RFC: disablenetwork facility. (v4)

[Valdis . Kletnieks]

On Mon, 28 Dec 2009 22:10:28 GMT, David Wagner said:

> Pavel responds:
> > Actually, I've seen a *lot* of similar [..] policies.

No, that was me, not Pavel.

> OK, so to translate: it sounds like the answer is No, you
> haven't seen this policy in real life.

As I point out in subsequent paragraphs, I *have* in fact seen systems that
implement essentially the same semantics.

> More to the point, the real question is whether this policy
> is embedded in code anywhere such that Michael's mechanism would
> introduce a new security hole, and if so, whether the cost of
> that would outweigh the benefit of his mechanism.

Granted - but "is it embedded in code anywhere" is different from "does
anybody use such a policy".  The semantic is used by many shops, but isn't
embedded in code anywhere that I know of - it's always done via system
config.

Take a standard stock Fedora install.  Configure it to use LDAP for user
authentication. Screw up the config with a typo.  Reboot to single user to fix,
you get a # prompt without entering a password. You now have Pavel's policy: 

>                 "If the network works, noone can
> log in locally, because administration is normally done over
> network. If the network fails, larger set of people is allowed in,
> because something clearly went wrong and we want anyone going around
> to fix it."

So yes, it *does* exist in the real world - unless there are *zero* Fedora
boxes that use LDAP, and haven't manually changed the init config to run
sulogin on a single-user boot.

> I think what Michael is trying to do has the potential to be very
> valuable and should be supported, and this is not a convincing
> argument against it.

In case you didn't notice, I've been on the "this looks sane if we can actually
do it correctly" side of the fence.  Michael's code isn't something I'd
personally run, because it doesn't address the threat models I worry about -
but I see the value for those people who do worry about them.

And hey, maybe we'll get lucky and we'll get the ability to have a stacker
that does MAC LSM + targeted add-ons, because in my world, the easiest fix
is the distributed SELinux 'mls' policy plus an add-on LSM - even though it's
likely that most of the stuff I want *could* be done via SELinux policy, in
many cases 20 lines of C is easier than retrofitting a policy patch or getting
the policy patch pushed upstream...

Out of curiosity, any of the other security types here ever included "getting
the damned semi-clued auditor who insists on cargo-cult checklists out of your
office" as part of your threat model?  Only a half-smiley on this one...

Attachment: pgp00000.pgp
Description: PGP signature