Bug 179761

Sorry, I meant to take it to the upstream selinux list, as it is an upstream issue.
But in any event, one question I have is what else does initng do, since the
current init scripts often do more than just start the daemon (e.g. they
sometimes create files or perform other setup)?  Will we ultimately need to
expand init_t to include all of the initrc_t permissions when using initng,
effectively collapsing those two types into one with the union permission set?

some daemons look like this:
daemon daemon/metalog {
        need = system/bootmisc;
        exec daemon = /usr/sbin/metalog -B -p /var/run/metalog.pid;
        pid_file = /var/run/metalog.pid;
}

the exec daemon line gets parsed by initng and executed.
some others have embed scripts like this:
daemon daemon/hald {
        need = system/bootmisc daemon/dbus;
        use = daemon/acpid;

        stdall = /dev/null;
        script daemon = {
                # Make sure, there is no stale processes running.
                killall hald
                killall -9 hald

                # Clear pid file.
                /bin/rm /var/run/hal/pid

                # We have to probe what version it is, they use different arguments.
                if /usr/sbin/hald --help 2>&1 | /bin/grep -- --retain-privileges
               then
                        exec /usr/sbin/hald --daemon=no --retain-privileges
                else
                        exec /usr/sbin/hald --daemon=no --drop-privileges
                fi
                exit 1
        };
}

they get executed via /bin/sh from inside initng.

Hmm...not good.  So instead of being able to keep init_t small and well-defined
and potentially being able to split up initrc_t into multiple separate domains
for different sets of rc scripts (possibly even down to per-script level) in the
future, init_t bloats into the union of init_t and initrc_t and we can't ever
provide finer-grained control.  

what about adding initng_t that has nothing to do with init_t? This would leave
init_t as is and gets initng to work.

initng_t would seem to be awfully close to initrc_t.

(In reply to comment #4)
> what about adding initng_t that has nothing to do with init_t? This would leave
> init_t as is and gets initng to work.

That is only delaying the issue, as initng is intended to replace SysVinit if it
works out, right?  At which point initng_t becomes init_t and the old init_t and
initrc_t go away.  And initng_t would seem to just be the union of init_t and
initrc_t, which can be done by typealiasing them together without touching the
rest of the allow and type_transition rules (unless there are conflicting
transitions defined).  But the real question is whether this architecture for
init is the one we want.

So a question for initng folks would be how bad would it be to have initng run a
helper (a separate executable) to perform the actions read from these config
files.  Then we could at least have it transition to initrc_t upon running that
helper program, and later we could instrument the helper to transition into
different domains for different services.  Would use of such a helper be
prohibitively costly for initng? 

so what is the solution now?

(In reply to comment #7)
> So a question for initng folks would be how bad would it be to have initng run a
> helper (a separate executable) to perform the actions read from these config
> files.  Then we could at least have it transition to initrc_t upon running that
> helper program, and later we could instrument the helper to transition into
> different domains for different services.  Would use of such a helper be
> prohibitively costly for initng? 

I passed the above question on to the initng mailing list. I got a short
question, which I'll just pass on back:

Can you change the policy while forking?

(In reply to comment #9)
> (In reply to comment #7)
> > So a question for initng folks would be how bad would it be to have initng run a
> > helper (a separate executable) to perform the actions read from these config
> > files.  Then we could at least have it transition to initrc_t upon running that
> > helper program, and later we could instrument the helper to transition into
> > different domains for different services.  Would use of such a helper be
> > prohibitively costly for initng? 
> 
> I passed the above question on to the initng mailing list. I got a short
> question, which I'll just pass on back:
> 
> Can you change the policy while forking?

its possible by using setexecon before doing it , but only if the policy allows
that.

Clarification:  Domain changes normally only occur upon execve, either
transparently based on policy rules or at the application's request via a prior
setexeccon(3) call if allowed by policy.  This is so that the domain change can
be bound to a particular entrypoint executable in policy and so that we have a
well-defined behavior for the inheritance of state across domains and the
initialization of the process in the new domain.  However, a newer setcon(3)
operation does permit "dynamic context transitions" ala setuid(2) for the rare
case where a program is already trusted to maintain separation between two
domains and wants to switch its credentials between them without performing an
exec.  Use of setcon(3) should be minimized, as it lacks the stronger guarantees
of exec-based transitions, but it does exist as an option.

Ok. I've done some research now. Scripts (like the one in comment #2) are
executed by a initng plugin, bash_launcher. Looking at the source of this plugin
I find that what happens in the heart of it is a simple execve /bin/sh. My
question thus is if it would solve things if we made another plugin which was
simply a copy of bash_launcher but with the exception that it instead used
something like /sbin/sel-initng-sh, which could practically be a copy (or maybe
even symlink?) of /bin/sh but that was classed as being initrc_t.

Or an even better solution could be a compile time argument that decided how
bash_launcher would launch scripts. Comments?

If you can change the plugin to run a helper program (which can even be a
script) that is labeled with initrc_exec_t, and have that helper run sh with the
arguments, then that should put things into the right context.  Longer term, you
might want to specify a particular context/type in the config language itself
for a particular daemon's "scriptlet" and have either the plugin or the helper
use setexeccon() to set the context to that value prior to calling execve.

Ah. Sounds to me that the best thing would be if the plugin itself would use
setexeccon() (Just before the execve) and set the context to whatever is set in
the service's .i file (using some new argument like "sel_context=foo"), or fall
back to setting it to initrc_exec_t. This way we wouldn't need any external
helper program at all. Right?

After some coding I came up with the following code in the bash_launcher plugin:

------------snip------------------------------------
#ifdef SELINUX
  const char *selinux_context = (&SELINUX_CONTEXT, s);
  if(selinux_context)
     setexeccon(selinux_context);
  else
     setexeccon("initrc_exec_t");
#endif
  execve("/bin/sh", argtmp, new_environ(s));
------------snip------------------------------------

Would this work? Could the policy be changed to allow this?

Strange, I didn't receive a copy of the last two comments.
In any event, setexeccon() requires a full context, not just the type, and it
needs the domain type (e.g. initrc_t) not the executable type that is supposed
to be on the file (e.g. initrc_exec_t).  You can construct a context by starting
with your own, then mutating the type, e.g.:

char *sestr = NULL;
context_t seref = NULL;

rc = getcon(&sestr);
if (rc < 0) goto fail;
seref = context_new(sestr);
if (!seref) goto fail;
if (context_type_set(seref, "initrc_t" /* or better, value read from config file
*/)) goto fail;
freecon(sestr);
sestr = context_str(seref);
if (!sestr) goto fail;
rc = setexeccon(sestr);
if (rc < 0) goto fail;

To allow it, policy would need to be adjusted to allow initrc_t
shell_exec_t:file entrypoint; since you are now directly transitioning to the
domain via sh rather than indirectly via an init script, but the real difference
is inconsequential since the shell is executed in both instances and the caller
has effective control.

Side bar:  Has the initng patch for loading policy been updated to match the FC5
 sysvinit selinux patch?  In FC5, we moved all of the policy loading logic into
libselinux, so sysvinit-selinux.patch is much simpler and we won't have to touch
init again to further adjust the policy load logic (which also changed due to
managed policy and the desire to eliminate the need for multiple policy.NN files
on disk).

(In reply to comment #16)
> In any event, setexeccon() requires a full context, not just the type, and it
> needs the domain type (e.g. initrc_t) not the executable type that is supposed
> to be on the file (e.g. initrc_exec_t).  You can construct a context by starting
> with your own, then mutating the type, e.g.:
> 
> char *sestr = NULL;
> context_t seref = NULL;
> 
> rc = getcon(&sestr);
> if (rc < 0) goto fail;
> seref = context_new(sestr);
> if (!seref) goto fail;
> if (context_type_set(seref, "initrc_t" /* or better, value read from config file
> */)) goto fail;
> freecon(sestr);
> sestr = context_str(seref);
> if (!sestr) goto fail;
> rc = setexeccon(sestr);
> if (rc < 0) goto fail;

Ok. I'll look at that next week. (I'm writing this "on the fly")

> To allow it, policy would need to be adjusted to allow initrc_t
> shell_exec_t:file entrypoint; since you are now directly transitioning to the
> domain via sh rather than indirectly via an init script, but the real difference
> is inconsequential since the shell is executed in both instances and the caller
> has effective control.

So what's the underline? Is this a good solution?

> Side bar:  Has the initng patch for loading policy been updated to match the FC5
>  sysvinit selinux patch?  In FC5, we moved all of the policy loading logic into
> libselinux, so sysvinit-selinux.patch is much simpler and we won't have to touch
> init again to further adjust the policy load logic (which also changed due to
> managed policy and the desire to eliminate the need for multiple policy.NN files
> on disk).

That's Dragoran's table (since he's the one who did all that work), but if I
understand correctly he didn't think it was any point fixing anything before we
had a policy that worked (see http://initng.org/ticket/365). Right, Dragoran?

Ok I have updated the patch in the initng bugzilla.
I also havn't dropped the old code (for FC4 and older support) and made a
configure switch for it.

patch commited to intng svn

domain_auto_trans(init_t, shell_exec_t, initrc_t) as has been suggested seems 
like the correct solution to this.

I'll add this to the policy if Dan doesn't beat me to it.

domain_auto_trans would conflict with the existing one for single-user mode (to
sysadm_t).  So I think you just want to authorize shell_exec_t as entrypoint,
and let initng use setexeccon to request the transition.

we also need to set the default context for /sbin/initng and it scripts in the
policy, but this should be a non issue right?

We have to set the context for /sbin/initng.  What are the scripts that it 
runs?  Are they run directly or via "sh -c script", if the latter then bin_t 
or sbin_t will be OK for them.

I had forgotten about the domain_auto_trans() for single user mode and hoped 
to reduce the amount of code changes required for initng.  domain_trans() is 
what we need to do.

the scripts are in /etc/initng see comment2 about how they work. 
when setting domain_trans() does this means that initng has to do setexecon to
initrc_t before running a script and the policy would start the daemons in their
correct domain?

If we want to run programs that are in unspecified/unknown (to the SE Linux 
configuration) locations then we need the setexeccon() call before running 
them.  If it's running scripts that are in a defined location such 
as /etc/initng then it can run them directly.  Note that due to the 
domain_auto_trans(init_t, shell_exec_t, sysadm_t) rule if initng 
executes "sh -c /etc/initng/whatever" (EG by using the system() library call) 
then this isn't going to work.  If however it just 
executes /etc/initng/whatever directly then all we need to do is to label the 
files /etc/initng/* as type initrc_exec_t and it should just work.

Please try running "chcon -t initrc_exec_t /etc/initng/*" and let me know what 
happens.

it does call execute them using sh
this means that a setexecon to initrc_t should work? or is a setexecon for each
script required?

So, what's happening to this issue? Now the selinux stuff is fixed and working
in initng, the only thing stopping it from really doing anything good is the
lack of policy...

Is it not working?  What avc messages are happening?  I do not use this so if we
do not receive new error information. how are we going to fix it?

Ah. I'm sorry. I thought it was a well known fact that it doesn't work yet. Here
are the avc's I get during a normal boot running selinux in permissive mode:

May 24 08:04:51 localhost kernel: audit(1148457856.220:3): avc:  denied  { write
} for  pid=335 comm="mount" name="[978]" dev=pipefs ino=978
scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:init_t:s0
tclass=fifo_file
May 24 08:04:51 localhost kernel: audit(1148457858.208:4): avc:  denied  { read
} for  pid=389 comm="pam_console_app" name="/" dev=tmpfs ino=726
scontext=system_u:system_r:pam_console_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
May 24 08:04:51 localhost kernel: audit(1148457858.208:5): avc:  denied  {
getattr } for  pid=389 comm="pam_console_app" name="/" dev=tmpfs ino=726
scontext=system_u:system_r:pam_console_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
May 24 08:04:51 localhost kernel: audit(1148457858.256:6): avc:  denied  {
search } for  pid=389 comm="pam_console_app" name="/" dev=tmpfs ino=726
scontext=system_u:system_r:pam_console_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir
May 24 08:04:53 localhost kernel: audit(1148457865.769:7): avc:  denied  { use }
for  pid=734 comm="mount" name="console" dev=tmpfs ino=756
scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:kernel_t:s0
tclass=fd
May 24 08:04:53 localhost kernel: audit(1148457865.889:8): avc:  denied  { use }
for  pid=739 comm="hwclock" name="console" dev=tmpfs ino=756
scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:kernel_t:s0
tclass=fd
May 24 08:04:53 localhost kernel: audit(1148457865.889:9): avc:  denied  { write
} for  pid=739 comm="hwclock" name="[39693]" dev=pipefs ino=39693
scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:init_t:s0
tclass=fifo_file
May 24 08:04:53 localhost kernel: audit(1148457865.893:10): avc:  denied  {
search } for  pid=739 comm="hwclock" name="/" dev=tmpfs ino=726
scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
tclass=dir
May 24 08:04:53 localhost kernel: audit(1148457865.929:11): avc:  denied  { use
} for  pid=738 comm="fsck" name="console" dev=tmpfs ino=756
scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:system_r:kernel_t:s0
tclass=fd
May 24 08:04:53 localhost kernel: audit(1148457865.997:12): avc:  denied  {
getattr } for  pid=740 comm="fsck.ext3" name="root" dev=tmpfs ino=788
scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
tclass=blk_file
May 24 08:04:53 localhost kernel: audit(1148457866.381:13): avc:  denied  {
getattr } for  pid=739 comm="hwclock" name="[39693]" dev=pipefs ino=39693
scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:init_t:s0
tclass=fifo_file
May 24 08:04:53 localhost kernel: audit(1148450670.609:14): avc:  denied  { use
} for  pid=935 comm="auditd" name="console" dev=tmpfs ino=756
scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:system_r:kernel_t:s0
tclass=fd
May 24 08:04:53 localhost kernel: audit(1148450670.609:15): avc:  denied  {
write } for  pid=935 comm="auditd" name="[40045]" dev=pipefs ino=40045
scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:system_r:init_t:s0
tclass=fifo_file
May 24 08:04:53 localhost kernel: audit(1148450670.641:16): avc:  denied  {
search } for  pid=948 comm="auditd" name="/" dev=tmpfs ino=726
scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
tclass=dir

Ok running your AVC through audit2allow shows the following

allow auditd_t init_t:fifo_file write;
allow auditd_t kernel_t:fd use;
allow auditd_t tmpfs_t:dir search;
allow fsadm_t kernel_t:fd use;
allow fsadm_t tmpfs_t:blk_file getattr;
allow hwclock_t init_t:fifo_file { getattr write };
allow hwclock_t kernel_t:fd use;
allow hwclock_t tmpfs_t:dir search;
allow mount_t init_t:fifo_file write;
allow mount_t kernel_t:fd use;
allow pam_console_t tmpfs_t:dir { getattr read search };

This looks like you have a kernel or something in initrd leaking a file
descriptor.  (kernel_t:fd use}.  

What is the tmpfs_t directory all the domains are trying to use?  This looks
like it could be a labeling problem.   

Finally do all of the domains need to talk to a fifo_file owned by init?  Or is
this also a leaky file descriptor?

some processes runs as kernel_t (like udev)
I don't know why yet.. 
and some run as unconfined_t
this maybe because initng changes the context for scripts that are executed
using sh -c to initrc_t and does the same for daemons that got executed directly
like dbus (and others).
Am I correct that setexecon() should *not* be used for such files because the
file context is used if it setexecon is not called? or will this resut in a
initrc_t domain for this service?

(In reply to comment #31)
> This looks like you have a kernel or something in initrd leaking a file
> descriptor.  (kernel_t:fd use}.  
>
> What is the tmpfs_t directory all the domains are trying to use?  This looks
> like it could be a labeling problem.   
> 
> Finally do all of the domains need to talk to a fifo_file owned by init?  Or is
> this also a leaky file descriptor?

I have absolutely no idea about this, I don't know much about selinux. The
computer from which the output comes is a clean Fedora devel system without
anything fancy (except for initng, installed from rpm).

I'm afraid I've lost the plot, so let's review the concept of operation for init:
/sbin/init (or initng) is going to start life as kernel_t, because the initial
task is kernel_t and we don't yet have a policy loaded to define a transition.
Then it needs to load policy and re-exec itself to get into the right domain
(init_t).
Then it needs to transition to initrc_t when running the scripts/scriptlets,
whether via setexeccon() prior to executing them or by labeling them with
initrc_exec_t.
Then the scripts/scriptlets should transition to the proper program domains when
they run those programs based on an existing transition rule in policy from
initrc_t to the program domain based on the file context.

If udev is still running in kernel_t, then it was started from a kernel_t
process (e.g. initng prior to re-exec?).
/dev will be left in tmpfs_t if you didn't restorecon it early (done via
rc.sysinit in current init system), since it is initially populated prior to
initial policy load.

The foo_t -> init_t:fifo_file denials indicate that the program domains are
inheriting a pipe back to an initng process running in init_t for output,
whereas current policy expects the pipe to go back to an initrc_t process.  If
the script/scriptlet ran in initrc_t, I would have expected it to create the
pipe for the program?

The foo_t -> kernel_t:fd denials indicate that a descriptor created by the
initial task or by initng prior to re-exec is being inherited by the descendants.  

ok now I added some fixes to the initng selinux plugin.
setexecon() is only used for scripts not for files executed directly but it
seems that this does not fix all problems. the files that are executed directly
still runs as init_t (no kernel_t this one is fixed ;))
I seems that the policy only does the auto trans stuff for files executed using
sh or bash, right? Why is udev running as init_t ? initng runs as init_t and
have executed it directly (no setexecon() call) , so why isn't the domain stored
in the fscontext of udev used? did I miss something here or does the policy
needs a fix for that?
I will add to attachments 
1) audit2allow output (note: I am not using auditd so all errors are in var log
messages which result in a full error log).
2) output of ps auxZ 

Created attachment 129981 [details]
audit2allow output

Created attachment 129982 [details]
ps auxZ output

(In reply to comment #35)
> setexecon() is only used for scripts not for files executed directly

Um, that won't work.  Let's go through the concept of operations again:
init (init_t) transitions to initrc_t upon executing an rc script (or shell in
the initng case, IIUC).
Then the rc script (or shell) transitions to the individual program domain upon
executing corresponding entrypoint executable.  There is no direct transition
from init_t to the individual program domains unless the program is already
directly started from inittab (e.g. getty, gdm).
So you always need the setexeccon() from initng so that the script or sh runs in
initrc_t (which just requires entrypoint permission for initrc_t to the script
files and shell), and then everything else should transition from them.


 

(In reply to comment #38)
> So you always need the setexeccon() from initng so that the script or sh runs in
> initrc_t (which just requires entrypoint permission for initrc_t to the script
> files and shell), and then everything else should transition from them.

Except for getty and [xgk]dm, where the current policy does only appear to
define a transition from init_t to them since they are started directly from
init.  However, we could likely add transitions from initrc_t for getty_t and
xdm_t in the policy so that either case will work, and then you wouldn't need to
special case them.

(In reply to comment #39)
> (In reply to comment #38)
> > So you always need the setexeccon() from initng so that the script or sh runs in
> > initrc_t (which just requires entrypoint permission for initrc_t to the script
> > files and shell), and then everything else should transition from them.
> 
> Except for getty and [xgk]dm, where the current policy does only appear to
> define a transition from init_t to them since they are started directly from
> init.  However, we could likely add transitions from initrc_t for getty_t and
> xdm_t in the policy so that either case will work, and then you wouldn't need to
> special case them.
> 

ok and what about udev why does it run as init_t ? seems that udev needs to be
added to the list too.
and what is still not working is that mount try to use kernel_t fds but which fd's ?
doing ls -Z /boot after booting does show the correct labels for the dev files.

(In reply to comment #40)
> ok and what about udev why does it run as init_t ? seems that udev needs to be
> added to the list too.

I assume you didn't setexeccon() to initrc_t before running sh -c
/sbin/start_udev or whatever it is initng is doing.  Normal transition under
init is init (init_t) -> rc.sysinit (initrc_t) -> start_udev (udev_t).

> and what is still not working is that mount try to use kernel_t fds but which
fd's ?
> doing ls -Z /boot after booting does show the correct labels for the dev files.

/boot or /dev?  rc.sysinit does a restorecon -R /dev under the current init
system to fix up the device nodes created prior to policy load.  Anything that
runs before that restorecon will see the files under the old type (tmpfs_t). 
The kernel_t fds are open file descriptions created by initng that are being
inherited by descendants, IIUC, e.g. to the console?  I assume SysVinit opens
them from the post-re-exec phase so that they are in init_t instead.

(In reply to comment #41)
> (In reply to comment #40)
> > ok and what about udev why does it run as init_t ? seems that udev needs to be
> > added to the list too.
> 
> I assume you didn't setexeccon() to initrc_t before running sh -c
> /sbin/start_udev or whatever it is initng is doing.  Normal transition under
> init is init (init_t) -> rc.sysinit (initrc_t) -> start_udev (udev_t).
> 
yes but initng uses execeve directly on udev (no sh involved)
(initng does this for many services like udev,dbus,httpd etc)
> > and what is still not working is that mount try to use kernel_t fds but which
> fd's ?
> > doing ls -Z /boot after booting does show the correct labels for the dev files.
> 
> /boot or /dev?  rc.sysinit does a restorecon -R /dev under the current init
> system to fix up the device nodes created prior to policy load. 
I mean /dev sorry.
initng does this too.
 Anything that
> runs before that restorecon will see the files under the old type (tmpfs_t). 
> The kernel_t fds are open file descriptions created by initng that are being
> inherited by descendants, IIUC, e.g. to the console?  I assume SysVinit opens
> them from the post-re-exec phase so that they are in init_t instead.
ok will try to find the fds

(In reply to comment #42)
> yes but initng uses execeve directly on udev (no sh involved)
> (initng does this for many services like udev,dbus,httpd etc)

Hmmm...I've definitely lost the plot then.  Domain transitions are based on the
caller domain and the executable, not just the executable.  The current policy
is built around the current model of SysVinit, where /sbin/init runs rc scripts
which perform the actual setup and run the daemons.  If you want initng to work
without duplicating transitions for both init_t and initrc_t to the daemon
domains, then you need to have it go through a helper (whether sh -c or
whatever) so that it can first transition to initrc_t and then execute the
actual daemon.

> I mean /dev sorry.
> initng does this too.

Then you shouldn't see any tmpfs_t denials for any processes run by initng after
doing that.

> ok will try to find the fds

Effectively this just means that the very first thing initng should do is load
policy and re-exec, then do all of its normal processing, such that the
descriptors are opened in the right domain from the beginning.  Same for SysVinit. 

(In reply to comment #43)
> (In reply to comment #42)
> > yes but initng uses execeve directly on udev (no sh involved)
> > (initng does this for many services like udev,dbus,httpd etc)
> 
> Hmmm...I've definitely lost the plot then.  Domain transitions are based on the
> caller domain and the executable, not just the executable.  The current policy
> is built around the current model of SysVinit, where /sbin/init runs rc scripts
> which perform the actual setup and run the daemons.  If you want initng to work
> without duplicating transitions for both init_t and initrc_t to the daemon
> domains, then you need to have it go through a helper (whether sh -c or
> whatever) so that it can first transition to initrc_t and then execute the
> actual daemon.
> 
ok will bring this issue upstream
> > I mean /dev sorry.
> > initng does this too.
> 
> Then you shouldn't see any tmpfs_t denials for any processes run by initng after
> doing that.
> 
hmm...
maybe the script isn't started early enough.....
> > ok will try to find the fds
> 
> Effectively this just means that the very first thing initng should do is load
> policy and re-exec, then do all of its normal processing, such that the
> descriptors are opened in the right domain from the beginning.  Same for
SysVinit. 
> 
> 
I did a stupid hack (for(i=0;i<=1013;i++) { close(i); } 
before the rexec line there where no more kernel_t fd avcs but init_t fd avcs
(this also resulted in initng was unable to print any output)

(In reply to comment #38)
> There is no direct transition
> from init_t to the individual program domains unless the program is already
> directly started from inittab (e.g. getty, gdm).

Just for the record, initng has nothing with inittab to do, inittab is SysVinit.
getties and dm's are started using .i-files just like everything else...

(In reply to comment #43)
> If you want initng to work
> without duplicating transitions for both init_t and initrc_t to the daemon
> domains, then you need to have it go through a helper (whether sh -c or
> whatever) so that it can first transition to initrc_t and then execute the
> actual daemon.

Ok. Sounds to me like this would only be a matter of hacking the same stuff into
simplelauncher that's been already been hacked into bash_launcher?

(Simplelauncher is the same thing as bash_launcher (see #12 for this), but for
the services that doesn't use scripts but just start a executable).

I'm doing some cleaning up of old bugs. Is this one still relevant, or could it
be closed?

we still need a solution to this, booting initng causes many avcs :( 
(=does not really work in enforcing mode)

Ok. Are we any closer to a solution than a year ago when this bug was opened?

we have less avcs now but the main issue are fd leaks (see #c44) and a missing
policy.

(In reply to comment #49)
> we have less avcs now

And I guess the number won't be zero without a policy, right?

> but the main issue are fd leaks (see #c44)

Ok. Is your hack (in the end of #44) something worth working on?

> and a missing policy.

This feels like the main issue. Who is to decide how this should work?

(I'm sorry if I'm asking stupid questions. I really haven't got much clue about
the workings of selinux. It seems to me that you (dragoran) is the only one that
knows anything about _both_ selinux _and_ initng...)

(In reply to comment #50)
> (In reply to comment #49)
> > we have less avcs now
> 
> And I guess the number won't be zero without a policy, right?
> 
no because of the way initng execute scripts see #2
> > but the main issue are fd leaks (see #c44)
> 
> Ok. Is your hack (in the end of #44) something worth working on?
> 
I think we should close fds wehn we no longer need them.
now it seems that initng keeps them open for ever. (have not checked this but
some are left open and without the selinux avcs they don't even get noticed)
> > and a missing policy.
> 
> This feels like the main issue. Who is to decide how this should work?
> 
> (I'm sorry if I'm asking stupid questions. I really haven't got much clue about
> the workings of selinux. It seems to me that you (dragoran) is the only one that
> knows anything about _both_ selinux _and_ initng...)

This should be solved like this:
1. fix the fd leaks
2. decide (with some help of the selinux maintainers) what exactly needs to be
changed in the policy. (use selinux-list or this bug report for this)
3. do the policy changes and release a update package.

whats the current status? any progress lately?

work is beeing done upstream to fix the fd leaking issues.
if you have time test initng-svn ;)

yeah my comment was more regarding the upstream issues. the fd leak fix is
supposed to be in svn :) i am just fixing other issues in svn and testing
iteratively to ensure the new release will work fine on fc6 / f7.

are you at some point online on irc drago? i think you wrote large parts of the
selinux support for initng and id have some questions regarding it.

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

This issue is still open/unfixed.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.