Re: Possible system call interface for LSM

From: Jesse Pollard (jesse@cats-chateau.net)
Date: Fri Aug 10 2001 - 19:59:27 PDT

  • Next message: James Morris: "Re: [patch] Socket Receive Hook"

    On Fri, 10 Aug 2001, Crispin Cowan wrote:
    >My main axe to grind here was that it should be a syscall, so I've been
    >quite through the rest of the debate, but thought I'd chip in here.
    ...
    >Richard seems to feel that 46 KB of kernel space for /proc is too much to
    >pay.  That seems a tad extreme to me: 46 KB is not much space for any
    >machine bigger than a wrist watch, and for larger systems, I suggest that
    >/proc will be included most of the time anyway.  So:
    >
    >   * Richard: what embedded applications are there that are that tight on
    >     memory, and also need B1 security? (1/2 :-)
    
    Not even secure routers - they arn't tight on memory.
    Perhaps a GPS reciever? Not since the declassification of the high resolution
    band...
    Weapons fire control ... but they SHOULDN'T be tight on memory.
    
    >   * Group: is there perhaps a cheaper way to indicate the presence of an
    >     LSM module than a /proc entry? Or is that really the Linux Way to do
    >     this, and we should stop with the fussing?
    
    None that I've run across - 
    	In spite of various opinions, even important ones... an ioctl IS
    	a system call interface... No more messy than some already existing
    	system calls (readv/writev, mount, quotactl, getgroups,...)
    
    	And it is a lot easier to control access, since a fileid must be
    	open to use it.
    
    	In my not so humble opinion, a /proc entry is quite suitable. Perhaps
    	permanently. Perhaps only until a real syscall is allocated. I do
    	like the idea of being able to determine WHAT process can use the
    	interface, and file access/lables is a clear way to do it.
    
    BTW, even if the interface is not in /proc, but with a filesystem of its' own,
    I would think that loading a LSM should be able to mount the filesystem
    itself. This has several advantages:
    
       1. eliminate the need to have it mounted externally to the module load
    	(after the module is loaded). 
       2. prevent the module from being unloaded (must dismount first)
       3. provide guaranteed verification if a dismount IS attempted
    
    -- 
    -------------------------------------------------------------------------
    Jesse I Pollard, II
    Email: jesse@cats-chateau.net
    
    Any opinions expressed are solely my own.
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Fri Aug 10 2001 - 20:24:07 PDT