Re: Policy tests failed

Re: Policy tests failed

[Daniel Gil Mayol]

Hello, I still have some problems with the policy tests.

I am testing that a domain can execute files that are defined in the 
policy. For example, lets take tripwire. In the policy is defined that:

    can_exec($1_t, shell_exec_t);
    can_exec($1_t, bin_t);

That means that tripwire_t domain is allowed to execute files labeled 
with shell_exec_t and bin_t.

The test first relabel as shell_exec_t a copy that I made previously of 
/bin/ls (this copy is under my test directory):

    [root@cnsu PolicyTest]# chcon -u system_u -r object_r -t shell_exec_t ls

Then I try to execute ls (under the domain tripwire_t) over a file 
called '/policytest' defined as:

    -rw-r--r--  root     root     system_u:object_r:policy_test_t 
    policytest

where policy_test_t is:

    type policy_test_t, file_type;
    allow * policy_test_t:file getattr;

But this execution fail:

    [root@cnsu PolicyTest]# runcon -t tripwire_t ./ls /policytest
    execvp: Permission denied

The /var/log/messages shows this:

Nov  2 11:06:46 cnsu kernel: audit(1162465606.392:25664): avc:  denied  
{ entrypoint } for  pid=27705 comm="runcon" name="ls" dev=hda2 
ino=240308 scontext=root:system_r:tripwire_t 
tcontext=system_u:object_r:shell_exec_t tclass=file

The question is... should I define for all the services this file 
entrypoint or I am doing something wrong in my test?
I would like to avoid to write all these entrypoints.


Thanks for your help

Dani






--
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: Policy tests failed

[Stephen Smalley]

On Thu, 2006-11-02 at 11:01 +0100, Daniel Gil Mayol wrote:
> Hello, I still have some problems with the policy tests.
> 
> I am testing that a domain can execute files that are defined in the 
> policy. For example, lets take tripwire. In the policy is defined that:
> 
>     can_exec($1_t, shell_exec_t);
>     can_exec($1_t, bin_t);
> 
> That means that tripwire_t domain is allowed to execute files labeled 
> with shell_exec_t and bin_t.
> 
> The test first relabel as shell_exec_t a copy that I made previously of 
> /bin/ls (this copy is under my test directory):
> 
>     [root@cnsu PolicyTest]# chcon -u system_u -r object_r -t shell_exec_t ls
> 
> Then I try to execute ls (under the domain tripwire_t) over a file 
> called '/policytest' defined as:
> 
>     -rw-r--r--  root     root     system_u:object_r:policy_test_t 
>     policytest
> 
> where policy_test_t is:
> 
>     type policy_test_t, file_type;
>     allow * policy_test_t:file getattr;
> 
> But this execution fail:
> 
>     [root@cnsu PolicyTest]# runcon -t tripwire_t ./ls /policytest
>     execvp: Permission denied
> 
> The /var/log/messages shows this:
> 
> Nov  2 11:06:46 cnsu kernel: audit(1162465606.392:25664): avc:  denied  
> { entrypoint } for  pid=27705 comm="runcon" name="ls" dev=hda2 
> ino=240308 scontext=root:system_r:tripwire_t 
> tcontext=system_u:object_r:shell_exec_t tclass=file
> 
> The question is... should I define for all the services this file 
> entrypoint or I am doing something wrong in my test?
> I would like to avoid to write all these entrypoints.

SELinux distinguishes between an executable that can be used to enter a
given domain (entrypoint) and an executable that can be subsequently
executed by that domain.  can_exec() only gives permissions for the
latter.  domain_trans() and domain_auto_trans() gives permissions for a
domain transition, including the entrypoint permission between the new
domain and the executable.  Example:
	domain_trans(unconfined_t, shell_exec_t, $1_t)
	domain_trans(unconfined_t, bin_t, $1_t)

Reference policy splits the entrypoint permission into a separate
macro/interface, domain_entry_file(), but that wouldn't exist in your
base policy.

-- 
Stephen Smalley
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: Policy tests failed

[Daniel Gil Mayol]

Stephen Smalley wrote:
> On Thu, 2006-11-02 at 11:01 +0100, Daniel Gil Mayol wrote:
>   
>> Hello, I still have some problems with the policy tests.
>>
>> I am testing that a domain can execute files that are defined in the 
>> policy. For example, lets take tripwire. In the policy is defined that:
>>
>>     can_exec($1_t, shell_exec_t);
>>     can_exec($1_t, bin_t);
>>
>> That means that tripwire_t domain is allowed to execute files labeled 
>> with shell_exec_t and bin_t.
>>
>> The test first relabel as shell_exec_t a copy that I made previously of 
>> /bin/ls (this copy is under my test directory):
>>
>>     [root@cnsu PolicyTest]# chcon -u system_u -r object_r -t shell_exec_t ls
>>
>> Then I try to execute ls (under the domain tripwire_t) over a file 
>> called '/policytest' defined as:
>>
>>     -rw-r--r--  root     root     system_u:object_r:policy_test_t 
>>     policytest
>>
>> where policy_test_t is:
>>
>>     type policy_test_t, file_type;
>>     allow * policy_test_t:file getattr;
>>
>> But this execution fail:
>>
>>     [root@cnsu PolicyTest]# runcon -t tripwire_t ./ls /policytest
>>     execvp: Permission denied
>>
>> The /var/log/messages shows this:
>>
>> Nov  2 11:06:46 cnsu kernel: audit(1162465606.392:25664): avc:  denied  
>> { entrypoint } for  pid=27705 comm="runcon" name="ls" dev=hda2 
>> ino=240308 scontext=root:system_r:tripwire_t 
>> tcontext=system_u:object_r:shell_exec_t tclass=file
>>
>> The question is... should I define for all the services this file 
>> entrypoint or I am doing something wrong in my test?
>> I would like to avoid to write all these entrypoints.
>>     
>
> SELinux distinguishes between an executable that can be used to enter a
> given domain (entrypoint) and an executable that can be subsequently
> executed by that domain.  can_exec() only gives permissions for the
> latter.  domain_trans() and domain_auto_trans() gives permissions for a
> domain transition, including the entrypoint permission between the new
> domain and the executable.  Example:
> 	domain_trans(unconfined_t, shell_exec_t, $1_t)
> 	domain_trans(unconfined_t, bin_t, $1_t)
>
> Reference policy splits the entrypoint permission into a separate
> macro/interface, domain_entry_file(), but that wouldn't exist in your
> base policy.
>
>   
And how can we test in our script this (that tripwire can execute types 
of shell_exec_t and bin_t) without define a domain_trans?
We don't want to allow this only for the test.



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

Policy tests failed

[Daniel Gil Mayol]

I am writting a policy over a RHEL4 customized kernel. I want to extend the 
current targeted policy (there are some new services to define a policy).

I want to test the policy, that is, the services should not have access 
(read/write/execute) to data that are not allowed. 
So I have written a script "exectest.py" labelled with a security context 
"system_u:object_r:XXX_t" where "type XXX_t, file_type;".

Lets say that we are testing the service "crond", so I execute "exectest.py 
crond". The first that do this script is execute an "id" and become the next:

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6
(disk),10(wheel) context=root:system_r:unconfined_t

Then the script try to read, write and execute files out of "crond_t" domain, 
that is, files labelled with types that I haven't allowed (for example bin_t, 
httpd_t). And the result is that it can.

I have tried also to write in the policy for example "neverallow crond_t 
bin_t : file { read write execute };" but still can access to these data.

When I execute this script, which domain it has? 
Can it be that it works in the unconfined domain and it has access to 
everything?

Thanks

--
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: Policy tests failed

[Stephen Smalley]

On Thu, 2006-10-19 at 17:00 +0200, Daniel Gil Mayol wrote:
> I am writting a policy over a RHEL4 customized kernel. I want to extend the 
> current targeted policy (there are some new services to define a policy).

Can you identify the particular policy version that you are using as
your baseline?

> I want to test the policy, that is, the services should not have access 
> (read/write/execute) to data that are not allowed. 
> So I have written a script "exectest.py" labelled with a security context 
> "system_u:object_r:XXX_t" where "type XXX_t, file_type;".

>From the above description, I am not clear as to how you are using the
type of the script.  Do you want to transition into a different domain
upon executing the script?  Or not?

> Lets say that we are testing the service "crond", so I execute "exectest.py 
> crond". The first that do this script is execute an "id" and become the next:
> 
> uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6
> (disk),10(wheel) context=root:system_r:unconfined_t

So the script starts off in the same context as the caller (unconfined
in this instance).  What do you mean by "become the next"?  Does it
execute the real crond?  Or run some test script using runcon -t crond_t
to put it into the crond_t domain?  Can you just post the script itself?

> Then the script try to read, write and execute files out of "crond_t" domain, 
> that is, files labelled with types that I haven't allowed (for example bin_t, 
> httpd_t). And the result is that it can.

Not clear what "out of the "crond_t" domain" means above - how did it
get into the crond_t domain?  How did you check that it actually ran in
that domain?

I'm also not sure how crond_t is defined in your policy; in targeted
policy, crond is unconfined.  In strict policy, it is confined, and
transitions to different domains depending on the job (e.g.
system_crond_t for system jobs, user_crond_t for ordinary user jobs,
sysadm_crond_t for root user crontab).  Naturally, system cron jobs
often require different permissions than user ones.

> I have tried also to write in the policy for example "neverallow crond_t 
> bin_t : file { read write execute };" but still can access to these data.

neverallow statements are assertions on the policy that are checked when
the policy is compiled.  So if you were able to successfully rebuild the
policy after adding such an assertion, then the policy should not
contain any allow rules granting such access.  But it isn't clear to me
that your script is ever executing in crond_t.

> When I execute this script, which domain it has? 

If you haven't defined a domain transition in your policy on the type
assigned to the script, then it stays in the caller's domain (in this
case, unconfined_t).  Unless the caller uses runcon or similar to
specifically run the script in a specified domain.

> Can it be that it works in the unconfined domain and it has access to 
> everything?

>From the output you posted, yes.  The id output showed it being
unconfined_t.

-- 
Stephen Smalley
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: Policy tests failed

[Daniel Gil Mayol]

[-- Attachment #1: Type: text/plain, Size: 5659 bytes --]

> On Thu, 2006-10-19 at 17:00 +0200, Daniel Gil Mayol wrote:
> > I am writting a policy over a RHEL4 customized kernel. I want to extend
> > the current targeted policy (there are some new services to define a
> > policy).
>
> Can you identify the particular policy version that you are using as
> your baseline?

The version number of the SELinux policy language that I am using to create 
the binary policy is 18 (policy.18).

> > I want to test the policy, that is, the services should not have access
> > (read/write/execute) to data that are not allowed.
> > So I have written a script "exectest.py" labelled with a security context
> > "system_u:object_r:XXX_t" where "type XXX_t, file_type;".
> >
> From the above description, I am not clear as to how you are using the
> type of the script.  Do you want to transition into a different domain
> upon executing the script?  Or not?

I want that the script makes a transition into a different domain. For this 
reason now I have the script relabel with the type "initrc_exec_t" and seems 
that after execute "runcon -t crond_t" it makes a transition to the crond_t 
domain.

> > Lets say that we are testing the service "crond", so I execute
> > "exectest.py crond". The first that do this script is execute an "id" and
> > become the next:
> >
> > uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6
> > (disk),10(wheel) context=root:system_r:unconfined_t
>
> So the script starts off in the same context as the caller (unconfined
> in this instance).  What do you mean by "become the next"?  

I mean I see the next message after start the script and "id" is executed 
(this is the problem of the literally translations :p  )

> Does it execute the real crond?  Or run some test script using runcon -t
> crond_t to put it into the crond_t domain?  Can you just post the script
> itself? 

The script don't execute crond, only prove that being in the crond_t domain 
can not access to data of another domain (for example httpd_exec_t).

> > Then the script try to read, write and execute files out of "crond_t"
> > domain, that is, files labelled with types that I haven't allowed (for
> > example bin_t, httpd_t). And the result is that it can.
>
> Not clear what "out of the "crond_t" domain" means above - how did it
> get into the crond_t domain?  How did you check that it actually ran in
> that domain?

Now the script get into anacron_t (now I am testing with anacron) domain using 
the command "runcon -t anacron_t". The script shows now after execute the 
command "id" the next:

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6
(disk),10(wheel) context=root:system_r:anacron_t

> I'm also not sure how crond_t is defined in your policy; in targeted
> policy, crond is unconfined.  In strict policy, it is confined, and
> transitions to different domains depending on the job (e.g.
> system_crond_t for system jobs, user_crond_t for ordinary user jobs,
> sysadm_crond_t for root user crontab).  Naturally, system cron jobs
> often require different permissions than user ones.

Here goes part of the script to test that a domain (ex. anacron) can only 
execute files that is allowed to (ex. anacron_exec_t):

###########     file: exectest.py     #############
   def testBin():
       result=True
       try:
           os.system(filedir+filename+" >/dev/null")
       except:
           result=False
 
      return result
##################################

Where 
   - filename: are all executable files. Derived from a "for" loop
   - filedir is a constant value with the directory where to find these files.

About execute runcon I've read the next mail from 
http://www.redhat.com/archives/fedora-selinux-list/2004-October/msg00105.html
------------------------------------------------------------------------------------------
I don't have any test scripts but i think rolling back the packages to one 
with a known vulerability would work, but since one goal of a hacker is to 
get a root shell, you could use runcon with a shell script to simulate what 
would happen if a hacker was successfull.
runcon -t httpd_t /bin/sh
Of course I can only get this to work in permissive mode. Setting it to 
enforcing kills the shell since it can not access the tty.
Also get an error "execvp: Permission denied" in enforcing.
-------------------------------------------------------------------------------------------
I thought I must run my policy test script in a enforce mode but I get the 
permission denied error (like the mail says). So, I have to run the script in 
permissive mode and look the 'audit denies' that appears 
in /var/log/messages?

> > I have tried also to write in the policy for example "neverallow crond_t
> > bin_t : file { read write execute };" but still can access to these data.
>
> neverallow statements are assertions on the policy that are checked when
> the policy is compiled.  So if you were able to successfully rebuild the
> policy after adding such an assertion, then the policy should not
> contain any allow rules granting such access.  But it isn't clear to me
> that your script is ever executing in crond_t.
>
> > When I execute this script, which domain it has?
>
> If you haven't defined a domain transition in your policy on the type
> assigned to the script, then it stays in the caller's domain (in this
> case, unconfined_t).  Unless the caller uses runcon or similar to
> specifically run the script in a specified domain.
>
> > Can it be that it works in the unconfined domain and it has access to
> > everything?
> >
> >From the output you posted, yes.  The id output showed it being
>
> unconfined_t.

[-- Attachment #2: Type: text/html, Size: 9174 bytes --]

Re: Policy tests failed

[Stephen Smalley]

(no html mail please)

On Fri, 2006-10-20 at 14:58 +0200, Daniel Gil Mayol wrote:
> The version number of the SELinux policy language that I am using to
> create the binary policy is 18 (policy.18).

I meant the policy package version, e.g. rpm -q selinux-policy-targeted
if using the RHEL 4 policy, or whatever you used as your baseline.

> I want that the script makes a transition into a different domain. For
> this reason now I have the script relabel with the type
> "initrc_exec_t" and seems that after execute "runcon -t crond_t" it
> makes a transition to the crond_t domain.

The above description suggests that you have two scripts, say "foo" and
"bar", and you have labeled "foo" with initrc_exec_t so that it
transitions to initrc_t automatically and the "foo" script contains a
line that does "runcon -t crond_t bar", where the "bar" script contains
the actual test code that you want to run in crond_t.  Is that correct?
BTW, in that case, "bar" should be labeled crond_exec_t.

> The script don't execute crond, only prove that being in the crond_t
> domain can not access to data of another domain (for example
> httpd_exec_t).

Ok, but the script itself needs to be run in crond_t then, which means
that it needs to be labeled with crond_exec_t.

> Now the script get into anacron_t (now I am testing with anacron)
> domain using the command "runcon -t anacron_t". The script shows now
> after execute the command "id" the next:
> 
> uid=0(root) gid=0(root)
> groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
> context=root:system_r:anacron_t

Ok, so the script is running in anacron_t in that case.  Whatever
anacron_t means in your particular policy.

> I don't have any test scripts but i think rolling back the packages to
> one with a known vulerability would work, but since one goal of a
> hacker is to get a root shell, you could use runcon with a shell
> script to simulate what would happen if a hacker was successfull.
> 
> runcon -t httpd_t /bin/sh
> 
> Of course I can only get this to work in permissive mode. Setting it
> to enforcing kills the shell since it can not access the tty.

There should be a boolean that controls tty access.
Try:
setsebool httpd_tty_comm=1

> Also get an error "execvp: Permission denied" in enforcing.

It needs to be labeled with the entrypoint type for the domain.
Try:
cp /bin/sh myhttpd
chcon -t httpd_exec_t myhttpd
runcon -t httpd_t ./myhttpd

> I thought I must run my policy test script in a enforce mode but I get
> the permission denied error (like the mail says). So, I have to run
> the script in permissive mode and look the 'audit denies' that appears
> in /var/log/messages?

No, you can test in enforcing mode but you have to set up the necessary
preconditions and you may need slightly customized policy to do it.

-- 
Stephen Smalley
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: Policy tests failed

[Daniel Gil Mayol]

> (no html mail please)
>
> On Fri, 2006-10-20 at 14:58 +0200, Daniel Gil Mayol wrote:
> > The version number of the SELinux policy language that I am using to
> > create the binary policy is 18 (policy.18).
>
> I meant the policy package version, e.g. rpm -q selinux-policy-targeted
> if using the RHEL 4 policy, or whatever you used as your baseline.

selinux-policy-targeted-1.17.30-2.126

> > I want that the script makes a transition into a different domain. For
> > this reason now I have the script relabel with the type
> > "initrc_exec_t" and seems that after execute "runcon -t crond_t" it
> > makes a transition to the crond_t domain.
>
> The above description suggests that you have two scripts, say "foo" and
> "bar", and you have labeled "foo" with initrc_exec_t so that it
> transitions to initrc_t automatically and the "foo" script contains a
> line that does "runcon -t crond_t bar", where the "bar" script contains
> the actual test code that you want to run in crond_t.  Is that correct?
> BTW, in that case, "bar" should be labeled crond_exec_t.

I have one script called  'exectest.py' labelled as 
system_u:object_r:initrc_exec_t. This script get a list of all the services 
to test. Then the "execute test" call one service of this list (supose 
anacron). All the services, with the name format 'SERVICE_NAME.exectest.py', 
are links to the script  'exectest.py' but labelled each one as 
'SERVICE_NAME_exec_t'. For example, anacron has the following link file:

lrwxrwxrwx  root     root     system_u:object_r:anacron_exec_t 
anacron.exectest.py -> /work/SElinux-test/exectest.py

The idea was the following, we have only one test script program (it is  
'exectest.py') and one link for each service (with the corresponding label).


> > The script don't execute crond, only prove that being in the crond_t
> > domain can not access to data of another domain (for example
> > httpd_exec_t).
>
> Ok, but the script itself needs to be run in crond_t then, which means
> that it needs to be labeled with crond_exec_t.
>
> > Now the script get into anacron_t (now I am testing with anacron)
> > domain using the command "runcon -t anacron_t". The script shows now
> > after execute the command "id" the next:
> >
> > uid=0(root) gid=0(root)
> > groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
> > context=root:system_r:anacron_t
>
> Ok, so the script is running in anacron_t in that case.  Whatever
> anacron_t means in your particular policy.
>
> > I don't have any test scripts but i think rolling back the packages to
> > one with a known vulerability would work, but since one goal of a
> > hacker is to get a root shell, you could use runcon with a shell
> > script to simulate what would happen if a hacker was successfull.
> >
> > runcon -t httpd_t /bin/sh
> >
> > Of course I can only get this to work in permissive mode. Setting it
> > to enforcing kills the shell since it can not access the tty.
>
> There should be a boolean that controls tty access.
> Try:
> setsebool httpd_tty_comm=1
>
> > Also get an error "execvp: Permission denied" in enforcing.
>
> It needs to be labeled with the entrypoint type for the domain.
> Try:
> cp /bin/sh myhttpd
> chcon -t httpd_exec_t myhttpd
> runcon -t httpd_t ./myhttpd
>
> > I thought I must run my policy test script in a enforce mode but I get
> > the permission denied error (like the mail says). So, I have to run
> > the script in permissive mode and look the 'audit denies' that appears
> > in /var/log/messages?
>
> No, you can test in enforcing mode but you have to set up the necessary
> preconditions and you may need slightly customized policy to do it.

I am trying also to use the macro for dbusd calling "dbusd_domain(system);" 
but I receive the following error:

domains/cnsu/messagebus.te:36:ERROR 'unknown boolean read_default_t in 
conditional expression' at token 'read_default_t' on line 30533:
if (read_default_t) {
#line 36
domains/cnsu/messagebus.te:36:ERROR 'illegal conditional expression' at token 
'allow' on line 30553:
allow system_dbusd_t { root_t usr_t lib_t etc_t }:dir { read getattr lock 
search ioctl };
#line 36




--
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: Policy tests failed

[Stephen Smalley]

On Mon, 2006-10-23 at 10:50 +0200, Daniel Gil Mayol wrote:
> I have one script called  'exectest.py' labelled as 
> system_u:object_r:initrc_exec_t. This script get a list of all the services 
> to test. Then the "execute test" call one service of this list (supose 
> anacron). All the services, with the name format 'SERVICE_NAME.exectest.py', 
> are links to the script  'exectest.py' but labelled each one as 
> 'SERVICE_NAME_exec_t'. For example, anacron has the following link file:
> 
> lrwxrwxrwx  root     root     system_u:object_r:anacron_exec_t 
> anacron.exectest.py -> /work/SElinux-test/exectest.py
> 
> The idea was the following, we have only one test script program (it is  
> 'exectest.py') and one link for each service (with the corresponding label).

That doesn't work; the context of the symlink isn't relevant to the
context transition on execve (just as the suid bit on a symlink is
irrelevant to setuid execution).  You would need to copy your script and
label the copy with the desired entrypoint type.

> I am trying also to use the macro for dbusd calling "dbusd_domain(system);" 
> but I receive the following error:
> 
> domains/cnsu/messagebus.te:36:ERROR 'unknown boolean read_default_t in 
> conditional expression' at token 'read_default_t' on line 30533:
> if (read_default_t) {
> #line 36
> domains/cnsu/messagebus.te:36:ERROR 'illegal conditional expression' at token 
> 'allow' on line 30553:
> allow system_dbusd_t { root_t usr_t lib_t etc_t }:dir { read getattr lock 
> search ioctl };
> #line 36

You must be using a macro that is normally only used in strict policy,
and thus lacks definitions it requires in the targeted policy.  In this
particular case, you could work around the issue by adding a:
	bool read_default_t false;
statement to your .te file.  But you may run into other problems with
using the macro due to other dependencies on strict policy.

Have you considered switching to strict policy?  RHEL 4 doesn't ship it,
but you can get an upstream one and build it yourself.  It takes a bit
of work to make the transition, but it already includes confined domains
for these processes.

-- 
Stephen Smalley
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: Policy tests failed

[Nayak Debabrata-a22788]

Hi Stephen,
I am a Security Architect at Motorola.
We are planning to implement SELinux IDS
For all our products. would you please suggest me
Which version will be best FIT for IDS.
I will be highly obliged to you.
With regards
debabrata


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