Re: Hooks for MAC

From: Chris Wright (chrisat_private)
Date: Mon Jul 30 2001 - 19:33:35 PDT

  • Next message: Lachlan McIlroy: "FW: Hooks for MAC (updated)"

    * Lachlan McIlroy (lachlanat_private) wrote:
    > > -----Original Message-----
    > > From: Chris Wright [mailto:chrisat_private]
    > > Sent: Tuesday, July 31, 2001 8:17 AM
    > > To: Lachlan McIlroy
    > > Cc: linux-security-moduleat_private
    > > Subject: Re: Hooks for MAC
    > > 
    > > 
    > > * Lachlan McIlroy (lachlan.mcilroyat_private) wrote:
    > > > 
    > > > The attached patch contains hooks required for a MAC
    > > > system to moderate subject-subject control.  These hooks
    > > > can be used to ensure that only processes with read/write
    > > > label dominance can read/write attributes of another
    > > > process (ie GID, SID and scheduling parameters).  The
    > > > patch was generated from the 2.4.6 tree and I will post
    > > > a patch against 2.4.7 soon.
    > > 
    > > This patch applies fine to the current 2.4.7 tree, so don't worry
    > > about making a new patch just yet.
    > 
    > Thanks for the effort.
    
    no prob ;-)
    > 
    > > 
    > > In all of setpgid, getpgid, getsid, and getscheduler you pass
    > > the task struct and it associated pid.  This is unecessary, as
    > > that's what (struct task_struct *)->pid is.  Could you please change
    > > this?
    > 
    > I'm working with SGI on this one so I included the system
    > call arguments for auditing purposes.  I see that they
    > are not necessary so I will remove all the pids but I
    > would like to keep the pgid in setpgid.
    
    of course, the pgid is indeed useful.
    
    > > 
    > > Do you have any need for a setsid hook?
    > 
    > The setsid system call operates on the current process
    > only.  It first scans all processes to see if it can
    > create a new session/group id from the current pid.  I
    > don't see a need to moderate processes during the scan
    > as no information about these processes is being returned
    > to the user.  (... and I have no intention of starting
    > another discussion about covert channels!)
    
    cool.  i wasn't actually concerned about the scan of the task list, but
    trying to imagine someone who might care that a program is trying to
    set its session id (typically done by a server after a fork when it's
    making itself a daemon).  i haven't really cared if someone can query
    your session id either, so we all have different needs... ;-)
    
    btw, you haven't closed every path to the session id.  /proc/pid/stat
    gives that info to you, see fs/proc/array.c:proc_pid_stat().
    
    > > 
    > > The getscheduler bit (just like setscheduler) collapses the getsched
    > > and getparam into one.  Do you think it would be useful to distinguish
    > > the two?  In setscheduler, we could simply add the sched_param to the
    > > interface...on get*...hmmm, does it really matter?
    > > 
    > 
    > For our purposes I see no need to distinguish the
    > getsched and getparam calls.  Does anybody else have a
    > need?
    > 
    > The sched_param argument in getparam is an output and
    > can be retreived from the task_struct if required.  The
    > sched_param argument in setscheduler could be useful for
    > access control and auditing so I'll add it to the
    > interface.
    
    sounds fine to me.
    
    -chris
    
    _______________________________________________
    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 : Mon Jul 30 2001 - 19:38:25 PDT