FAM uses seteuid and setegid

FAM uses seteuid and setegid

[Luke Kenneth Casson Leighton]

hi,

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").

hum.

-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
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.

Re: FAM uses seteuid and setegid

[Stephen Smalley]

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 (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.  

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: FAM uses seteuid and setegid

[Luke Kenneth Casson Leighton]

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.

Re: FAM uses seteuid and setegid

[Stephen Smalley]

On Thu, 2004-05-20 at 09:55, Luke Kenneth Casson Leighton wrote:
> > 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?

- You can certainly read the inline documentation in
include/selinux/avc.h, and get more information from the original tech
report and background papers about the interface.

- The userspace AVC was derived from the kernel AVC, so the SELinux
kernel module provides an example of how to use avc_has_perm.  But there
are certain differences, particularly with respect to obtaining SIDs
(since kernel SIDs are not exported to userspace, so the userspace AVC
maintains its own mapping) and the callbacks required for the userspace
AVC to encapsulate operations like memory allocation and threading.

- Since the userspace AVC is relatively new, there are only two present
users of it: security-enhanced X and security-enhanced dbus.  See Eamon
Walsh's posting about security-enhanced X.  He created the userspace AVC
from the kernel AVC to support that work, thus addressing a longstanding
item on our todo list for providing full support for userland policy
enforcers.  Security-enhanced X is likely the best example of how to use
the userspace AVC and is the most readily available (see Eamon's posting
for the CVS information).

- Note that avc_has_perm internally calls security_compute_av when the
decision is not in the cache.  If you look at some of the existing
SELinux patches (e.g. cron, pam_rootok), you'll see that they directly
call security_compute_av.  Since we didn't have a userspace AVC when
those patches were created and since it wasn't clear that there would be
a strong benefit from a userspace AVC for those particular programs,
they simply directly invoke the security_compute_av interface.  For
famd, it likely makes sense to cache decisions for performance.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: FAM uses seteuid and setegid

[Stephen Smalley]

On Thu, 2004-05-20 at 09:55, Luke Kenneth Casson Leighton wrote:
>  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()?

I haven't looked at the famd code.  But the man page says that it only
gives out the names of monitored files, and it only monitors files that
the client can stat().  Hence, the client only needs search permission
to every directory in the path leading to the file, and getattr
permission to the file itself.  If famd is opening each directory
component with opendir(), then you can use dirfd() to get the descriptor
for the directory component, then apply fgetfilecon() to gets its
security context, and check search permission from the client to that
directory context.  Then you need to check getattr permission to the
final component, and try to minimize the likelihood of a race (but note
that you cannot open the final component, as that would violate the
model).

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: FAM uses seteuid and setegid

[Russell Coker]

On Thu, 20 May 2004 22:15, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 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.

Famd is badly designed for security.  There has been talk of replacing that 
functionality with other code, the general concept is that for a local FAM 
you just have the first process to call it fork off a child process which 
executes a famd in the user context, then other processes with the same UID 
can connect to the same famd.

-- 
http://apac.redhat.com/disclaimer
See above URL for disclaimer.

--
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.

Re: FAM uses seteuid and setegid

[Luke Kenneth Casson Leighton]

On Fri, May 21, 2004 at 01:14:53AM +1000, Russell Coker wrote:
> On Thu, 20 May 2004 22:15, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > 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.
> 
> Famd is badly designed for security.  There has been talk of replacing that 
> functionality with other code, the general concept is that for a local FAM 
> you just have the first process to call it fork off a child process which 
> executes a famd in the user context, then other processes with the same UID 
> can connect to the same famd.
 
 that's much more sensible.


--
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.

Re: FAM uses seteuid and setegid

[Stephen Smalley]

On Thu, 2004-05-20 at 12:24, Luke Kenneth Casson Leighton wrote:
> > Famd is badly designed for security.  There has been talk of replacing that 
> > functionality with other code, the general concept is that for a local FAM 
> > you just have the first process to call it fork off a child process which 
> > executes a famd in the user context, then other processes with the same UID 
> > can connect to the same famd.
>  
>  that's much more sensible.

Yes, but unfortunately it doesn't help with remote FAM usage, which
isn't uncommon.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: FAM uses seteuid and setegid

[Russell Coker]

On Fri, 21 May 2004 02:32, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> On Thu, 2004-05-20 at 12:24, Luke Kenneth Casson Leighton wrote:
> > > Famd is badly designed for security.  There has been talk of replacing
> > > that functionality with other code, the general concept is that for a
> > > local FAM you just have the first process to call it fork off a child
> > > process which executes a famd in the user context, then other processes
> > > with the same UID can connect to the same famd.
> >
> >  that's much more sensible.
>
> Yes, but unfortunately it doesn't help with remote FAM usage, which
> isn't uncommon.

We can still use the current version of famd for remote use, it just becomes 
an option that does not need to be installed.  Previously famd was required 
for any fully functional desktop system, which is not what we want.

-- 
http://apac.redhat.com/disclaimer
See above URL for disclaimer.

--
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.