lkml.org 
[lkml]   [2007]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux Security *Module* Framework (Was: LSM conversion to static interface)
    I have different deal breakers.

    If a LSM is something simple/commonly required it should be made like
    posix file capability's provided to all to use. Sorry to say I see
    the file protection in apparmor as something everyone should be able
    to use at will like posix file capability's. All enforcement features
    should be common.

    I see a LSM as a director commander its reason for existence is to
    read security configs and hand them permissions and respond to
    problems. Any enforcement should be default in kernel.

    So LSM could be roll based, mac or any other model. Current problem
    enforcement and guiding are mixed up in one block. So evolution is
    not happening.

    The enforcing bits of LSM's should be a simple no brainier addons to
    the Linux kernel. The problem is at moment they are mixed up with Mac
    .... A security model to use has to be picked to suit job. Role
    Based can be Better than Mac and Mac can be better than Role based.
    It all depends on what you are defending.

    Thing common all need to protect suid, file access, network access...
    The bits you need to defend don't change if or if not you are running
    a LSM. So why are these bits bottled up inside LSM forcing people to
    choose the wrong security model for there task to get protection at
    times.

    There can never be one LSM to do every job. But the big but all the
    common bits to protect every job could be in kernel. Only thing
    missing is the director.

    This is exactly the same problem Virtual Server solutions had when
    then wanted to get into the kernel. At least the Virtual Server
    solutions were not as pig headed as some of the LSM guys about it.
    Where its all in or not in at all. Little bits into kernel is better
    than nothing.

    Really this will sound bad if I had my way I would kick all LSM's out
    of the main kernel tree until they learn to work with each other to
    share bits. We don't need 10 copies of protect files from access. Or
    10 copies of limit what .so a application and interface with and so
    on.

    It worked with Virtual Servers to get them to sit down and start
    talking. What we really need working on is system wide security. No
    bothering a lot about the little box of LSM.

    Yes I am not nice to LSM. I see them as bitrot. They are going to
    cause containers problems in there current form as containers evolve.
    They are not improving the base line security level. Yes selinux
    saying make me default to improve secuity says that in selinux there
    are parts that should be chopped out and made default. But since it
    contains a security model it cannot be all made default because it
    just will not fit everywhere.

    Basically a LSM should make it simpler to run security tight. The big
    all mighty but it should not alter achievable security. If its
    altering achievable security main kernel is missing features and
    someone needs to slice and dice that LSM.

    Peter Dolding
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-10-25 03:29    [W:4.159 / U:0.576 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site