Definition of "default deny"

Discussion in 'other security issues & news' started by Gullible Jones, Apr 25, 2014.

Thread Status:
Not open for further replies.
  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,466
    Because I feel like I need to clear the air about this stuff...

    There seems to be a lot of thinking here that "default deny" as per the famous Marcus Ranum article translates into "don't let any applications run other than those you need." This is an oversimplification. "Default deny" is applicable on a lot more levels. Executable whitelisting is just a small part of it; other parts of the policy may apply:

    Within desktop applications. e.g.
    - Browsers should not run Java/Flash/Javascript on untrusted pages, and should not load any third-party content on any page unless told otherwise
    - PDF viewers, office applications, etc. should not load scripts or macros unless the user allows it for that specific document

    In networking. e.g.
    - Ports should be blocked if services listening on them are not needed
    - Non-listening network services should not be running if not needed
    - Necessary network services should only be configured to connect where they have to
    - Automatic discovery and configuration services (Zeroconf/Avahi, etc.) should not be running

    In OS internals. e.g.
    - Users should not be allowed more privileges than they need (including admins, who should use limited accounts for non-administrative tasks)
    - Applications that are allowed to run should only be given access to the resources they require (i.e. mandatory access control implementing the principle of least privilege, or at least some semblence thereof)
    - Per default, applications are not allowed to execute data regions of memory, or flag data regions as executable (i.e. NX bit and mprotect() restriction; the latter is implemented by very few OSes)

    That's just a sampling of the places that this applies.

    Point is, a lot of times what people here mean when they say "I use a default-deny setup" is actually "I use a whitelist policy for binary executables." Which is usually not a bad thing, but there is quite a lot it doesn't cover.

    ---

    And now a bit of theoretical fluff...

    There have for some time been (experimental) OSes that take default-deny to an extreme level; they implement capabilities, which basically means that any and every resource is accessed through something like a file descriptor, handed to the process by the kernel and applicable only to that resource.

    There's also a (likewise experimental) implementation of capabilities for FreeBSD, as an extension of POSIX standards... And now for Linux too:

    http://www.cl.cam.ac.uk/research/security/capsicum/

    And I believe Microsofty has also hired some people from the capability-based security arena. Good news I'd think.
     
  2. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    A good description of default-deny. A whitelist for executables is the most common place to start implementing default-deny, but it is only the beginning.
    I would add the PDF reader and media player to that list of things browsers shouldn't be allowed to do. Likewise the PDF reader shouldn't be able to launch the browser. Javascript doesn't have to be limited to enabled or disabled. Default-deny can be applied to javascript with a filtering proxy, or to an extent using an extension like NoScript.
    Services that aren't essential to the OS and not required by the user can be completely disabled or removed entirely. Windows updates have a way of changing user settings at times, including re-enabling services that the user shut down.

    Capabilities looks quite interesting. Thanks for the link.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.