issetugid() for other procs

Any way to check if another proc has run or been run by a
proc that
is setuid or seteuid?
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

man getuid, man geteuid.

Cheers,

j.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Sun, 07 Oct 2007 18:25:57 +0200
Jan Münther <jan.muenthernruns.com> wrote:

> man getuid, man geteuid.

This does work for other procs, only the one that is calling
it.

Like I said initially I am looking to check if another proc
has run
setuid, seteuid, or been executed or forked by one that
has.

_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Sun, 7 Oct 2007 21:04:02 +0300
Kostik Belousov <kostikbelgmail.com> wrote:

> On Sun, Oct 07, 2007 at 12:28:05PM -0500, Zane C.B.
wrote:
> > On Sun, 07 Oct 2007 18:25:57 +0200
> > Jan M?nther <jan.muenthernruns.com> wrote:
> > 
> > > man getuid, man geteuid.
> > 
> > This does work for other procs, only the one that
is calling it.
> > 
> > Like I said initially I am looking to check if
another proc has
> > run setuid, seteuid, or been executed or forked by
one that has.
> 
> Note that what you trying to do is racy by definition.

Why is that? It seems like something that be useful instead
of
something taboo. My interest in it is I am writing a
database
connector interested in making it paranoid as possible.

> To get the value of issetugid() for some other process,
as it
> _could_ be returned at some moment in a time, you shall
check the
> P_SUGID bit of the p_flag from the corresponding struct
proc. This
> is available by the kvm_getprocs(3) interface in the
ki_flag field
> of the kinfo_proc structure, see corresponding man
page.

Awesome, I will begin investigating this.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Sun, Oct 07, 2007 at 01:39:17PM -0500, Zane C.B. wrote:
> On Sun, 7 Oct 2007 21:04:02 +0300
> Kostik Belousov <kostikbelgmail.com> wrote:
> 
> > On Sun, Oct 07, 2007 at 12:28:05PM -0500, Zane
C.B. wrote:
> > > On Sun, 07 Oct 2007 18:25:57 +0200
> > > Jan M?nther <jan.muenthernruns.com> wrote:
> > > 
> > > > man getuid, man geteuid.
> > > 
> > > This does work for other procs, only the one
that is calling it.
> > > 
> > > Like I said initially I am looking to check
if another proc has
> > > run setuid, seteuid, or been executed or
forked by one that has.
> > 
> > Note that what you trying to do is racy by
definition.
> 
> Why is that? It seems like something that be useful
instead of
> something taboo. My interest in it is I am writing a
database
> connector interested in making it paranoid as
possible.

Because you do not control the execution of the other
process. As
consequence, value you get is outdated even before you start
using it.

On Sun, 7 Oct 2007 21:53:14 +0300
Kostik Belousov <kostikbelgmail.com> wrote:

> On Sun, Oct 07, 2007 at 01:39:17PM -0500, Zane C.B.
wrote:
> > On Sun, 7 Oct 2007 21:04:02 +0300
> > Kostik Belousov <kostikbelgmail.com> wrote:
> > 
> > > On Sun, Oct 07, 2007 at 12:28:05PM -0500,
Zane C.B. wrote:
> > > > On Sun, 07 Oct 2007 18:25:57 +0200
> > > > Jan M?nther <jan.muenthernruns.com> wrote:
> > > > 
> > > > > man getuid, man geteuid.
> > > > 
> > > > This does work for other procs, only the
one that is calling
> > > > it.
> > > > 
> > > > Like I said initially I am looking to
check if another proc
> > > > has run setuid, seteuid, or been
executed or forked by one
> > > > that has.
> > > 
> > > Note that what you trying to do is racy by
definition.
> > 
> > Why is that? It seems like something that be
useful instead of
> > something taboo. My interest in it is I am writing
a database
> > connector interested in making it paranoid as
possible.
> 
> Because you do not control the execution of the other
process. As
> consequence, value you get is outdated even before you
start using
> it.

Yeah, this is another thing I need to look into. I need to
look into
how to go about figuring out if a program can be trusted or
not. Just
got thinking that any thing that has been run will have been
run by
something that ran it setuid.

The project I am looking into is creating a database
connector
daemon and related pam module. When a user logs in their
password
they used is shoved into the PAM module and then a
application can
be used for accessing the database.

Any thoughts in that area?

My large interest in this is in regards to LDAP.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Sun, Oct 07, 2007 at 12:28:05PM -0500, Zane C.B. wrote:
> On Sun, 07 Oct 2007 18:25:57 +0200
> Jan M?nther <jan.muenthernruns.com> wrote:
> 
> > man getuid, man geteuid.
> 
> This does work for other procs, only the one that is
calling it.
> 
> Like I said initially I am looking to check if another
proc has run
> setuid, seteuid, or been executed or forked by one that
has.

Note that what you trying to do is racy by definition.

To get the value of issetugid() for some other process, as
it _could_
be returned at some moment in a time, you shall check the
P_SUGID bit
of the p_flag from the corresponding struct proc. This is
available by
the kvm_getprocs(3) interface in the ki_flag field of the
kinfo_proc
structure, see corresponding man page.