Re: FAM uses seteuid and setegid

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Thu, May 20, 2004 at 08:42:26AM -0400, Stephen Smalley wrote:

> On Thu, 2004-05-20 at 08:15, Luke Kenneth Casson Leighton wrote:
> > just taking a look at famd, which uses seteuid and setegid before
> > going and 'avin a look at files (Cred::Implementation::become_user())
> > 
> > so, famd is designed to "effectively" set its user and group ids,
> > such that any file access is done as these, whilst still remaining
> > actually running as root.
> > 
> > ... so... what tricks can be done that are equivalent to this?
> > 
> > setfscreatecon doesn't apply because that's presumably for file
> > creation, and famd does file access not file creation.
> > 
> > setexeccon doesn't apply because there _are_ no relevant exec
> > calls that occur in famd, and the only forks() and execs()
> > are to run programs (e.g. "insmod imon").
> 
> You can either a) re-architect the application to use a
> fork/setexeccon/exec model or b) have the application perform access
> checking itself on behalf of the user context via avc_has_perm 

 is there any example code about that does this, or what's the closest
 GPL project that you are aware of that does something with
 avc_has_perm?

 [as you might have noticed cut/paste is my best friend.]

 it will be necessary... eek... to reject even directory accesses
 (opendir) as well.

 hm.

 *thinks*...
 
 ... this is unix.  therefore if you can opendir(), you can at least
 see all the entries.

 ACCESS to the entries is another matter.

 so.

 the question becomes (and assuming that avc_has_perm can do
 directory stuff, which yeh it would be :) is it only necessary
 to do an avc_has_perm on each opendir(), as opposed to doing
 an avc_has_perm on each readdir()?

 or, should i be doing an avc_has_perm( ... READ_PERM ... )
 on every opendir() and then ... say...
 an avc_has_perm ( ... EXECUTE_PERM ... ) on every entry in the
 readdir()?


 or, should i just forget this and live with the terrible but
 serviceable https://listman.redhat.com/archives/fedora-selinux-list/2004-April/msg00297.html

> (but note
> the potential for TOCTTOU issues there, although this may be irrelevant
> for fam as it only monitors files for changes; it doesn't provide access
> to the files themselves).
> 
> Reasons why we don't support a setuid-like operation for security
> contexts have been discussed previously on the list a number of times.  
 
 oh, okie.

 i can't think of any good reasons for a setuid-like operation: however,
 a seteuid-like one i can imagine _some_ reasons, and they all end up
 with the programmer having to remember what's going on, which is Not
 Good.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.