Re: Hooks for MAC

chrisat_private

* 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