Re: RFC: disablenetwork facility. (v4)

Pavel writes:
Policy may well be "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."

Michael Stone writes:
Have you actually seen this security policy in real life?

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

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

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. I think the
answer is, No, no one even has a plausible story for how this
policy might appear in some legacy executable that would then
be newly subvertible due to Michael Stone's policy. First off,
this sounds like a pretty wacko policy. Second, it's unlikely
to be embedded in a setuid-root executable that anyone can
execute. Third, if there were such a setuid-root executable
(which I've already argued is in fantasy land, but let's suppose
pigs could fly and such a thing existed in practice), there are
other ways to attack it: such as by using up all available
file descriptors and then forking and execing that executable.
Fourth, even if it existed, it would be a very rare one-off
site-specific thing. But most importantly, we're way off the
rails onto speculation. Of course you can always imagine some
conceivable scenario under which any new mechanism might have
unwanted side effects -- that's just the nature of any complex
system -- but I don't see any reasonable argument at all that
Michael's mechanism will cause more harm than good.

Bottom lien: I agree with Michael Stone. I think this
objection is weak.

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps
    ... partition, and AT THE SAME TIME want stuff to execute from there (being ... IMHO there should be some policy that can be achieved. ... suggests that there is no strict policy at all any more. ...
    (Linux-Kernel)
  • Re: Rule No fire
    ... > .Net document type of your schema that the rules will execute on. ... > are able to select your message as a parameter for the policy you are ... >>the orchestration is executed, the polict is loaded but no rule is fired ...
    (microsoft.public.biztalk.server)
  • Re: Preventing users installing programms...?
    ... Anyhow see the link below for the policy I was mentioning. ... To restrict users from running specific Windows programs on a standalone Windows ... >>can change permissions back to allow execute. ...
    (microsoft.public.win2000.security)
  • Re: BizTalk 2004 Business Rule Engine
    ... You are not deploying an assembly when you deploy rules, ... policy by name, and then pass in facts to the engine and execute the policy. ... > thing I am facing is when I deploy the Policy from Business Rule ...
    (microsoft.public.biztalk.general)