sshd error: Failed to get default security context

sshd error: Failed to get default security context

[Larry Ross]

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

I have created a custom selinux user for the strict policy on RHEL5.3 who's
purpose is to connect via ssh and scp files off the machine.  When that user
tries to login via ssh, I see the following messages in /var/log/secure:

In enforcing:
Oct 16 07:49:40 localhost sshd[20461]: Accepted password for scpuser
from 192.168.1.1 port 64680 ssh2
Oct 16 07:49:40 localhost sshd[20461]: error: Failed to get default security
context for scpuser.
Oct 16 07:49:40 localhost sshd[20461]: fatal: SELinux failure. Aborting
connection.

In permissive:
Oct 16 07:55:59 localhost sshd[23302]: Accepted password for scpuser from
192.168.1.1 port 56254 ssh2
Oct 16 07:55:59 localhost sshd[23302]: error: Failed to get default security
context for scpuser.
Oct 16 07:55:59 localhost sshd[23302]: error: SELinux failure. Continuing in
permissive mode.

Could someone explain what these messages mean?

I believe that I have a default context defined in the "default context"
file that should work. I believe I have an executable context available for
this user (using rbash rather than bash).

How is sshd making this decision?  It looks like it is calling setexeccon,
but I'm not sure how that makes its decision.  Where should I look for clues
as to how to fix it?

   Thank you,
   Larry

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

Re: sshd error: Failed to get default security context

[Daniel J Walsh]

On 10/16/2009 08:15 PM, Larry Ross wrote:
> I have created a custom selinux user for the strict policy on RHEL5.3 who's
> purpose is to connect via ssh and scp files off the machine.  When that user
> tries to login via ssh, I see the following messages in /var/log/secure:
> 
> In enforcing:
> Oct 16 07:49:40 localhost sshd[20461]: Accepted password for scpuser
> from 192.168.1.1 port 64680 ssh2
> Oct 16 07:49:40 localhost sshd[20461]: error: Failed to get default security
> context for scpuser.
> Oct 16 07:49:40 localhost sshd[20461]: fatal: SELinux failure. Aborting
> connection.
> 
> In permissive:
> Oct 16 07:55:59 localhost sshd[23302]: Accepted password for scpuser from
> 192.168.1.1 port 56254 ssh2
> Oct 16 07:55:59 localhost sshd[23302]: error: Failed to get default security
> context for scpuser.
> Oct 16 07:55:59 localhost sshd[23302]: error: SELinux failure. Continuing in
> permissive mode.
> 
> Could someone explain what these messages mean?
> 
> I believe that I have a default context defined in the "default context"
> file that should work. I believe I have an executable context available for
> this user (using rbash rather than bash).
> 
> How is sshd making this decision?  It looks like it is calling setexeccon,
> but I'm not sure how that makes its decision.  Where should I look for clues
> as to how to fix it?
> 
>    Thank you,
>    Larry
> 
Did you add an entry to default_types?

--
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: sshd error: Failed to get default security context

[Larry Ross]

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

On Sat, Oct 17, 2009 at 4:39 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:

>  On 10/16/2009 08:15 PM, Larry Ross wrote:
> > I have created a custom selinux user for the strict policy on RHEL5.3
> who's
> > purpose is to connect via ssh and scp files off the machine.  When that
> user
> > tries to login via ssh, I see the following messages in /var/log/secure:
> >
> > In enforcing:
> > Oct 16 07:49:40 localhost sshd[20461]: Accepted password for scpuser
> > from 192.168.1.1 port 64680 ssh2
> > Oct 16 07:49:40 localhost sshd[20461]: error: Failed to get default
> security
> > context for scpuser.
> > Oct 16 07:49:40 localhost sshd[20461]: fatal: SELinux failure. Aborting
> > connection.
> >
> > In permissive:
> > Oct 16 07:55:59 localhost sshd[23302]: Accepted password for scpuser from
> > 192.168.1.1 port 56254 ssh2
> > Oct 16 07:55:59 localhost sshd[23302]: error: Failed to get default
> security
> > context for scpuser.
> > Oct 16 07:55:59 localhost sshd[23302]: error: SELinux failure. Continuing
> in
> > permissive mode.
> >
> > Could someone explain what these messages mean?
> >
> > I believe that I have a default context defined in the "default context"
> > file that should work. I believe I have an executable context available
> for
> > this user (using rbash rather than bash).
> >
> > How is sshd making this decision?  It looks like it is calling
> setexeccon,
> > but I'm not sure how that makes its decision.  Where should I look for
> clues
> > as to how to fix it?
> >
> >    Thank you,
> >    Larry
> >
> Did you add an entry to default_types?
>

I did.  And in default_contexts and in users/scpuser.  None of them fixed
the issue.
Could someone explain to me if these files are still used and what they are
used for?  And if there are other files that might need to be modified as
well?

At this point it looks like I was missing a rule to allow the role
transition, but it isn't quite fixed yet (and some of the entries in the
files above may or not have been required as well).

  -- Larry

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

Re: sshd error: Failed to get default security context

[Stephen Smalley]

On Sat, 2009-10-17 at 11:17 -0700, Larry Ross wrote:
> 
> 
> On Sat, Oct 17, 2009 at 4:39 AM, Daniel J Walsh <dwalsh@redhat.com>
> wrote:
>         
>         On 10/16/2009 08:15 PM, Larry Ross wrote:
>         > I have created a custom selinux user for the strict policy
>         on RHEL5.3 who's
>         > purpose is to connect via ssh and scp files off the
>         machine.  When that user
>         > tries to login via ssh, I see the following messages
>         in /var/log/secure:
>         >
>         > In enforcing:
>         > Oct 16 07:49:40 localhost sshd[20461]: Accepted password for
>         scpuser
>         > from 192.168.1.1 port 64680 ssh2
>         > Oct 16 07:49:40 localhost sshd[20461]: error: Failed to get
>         default security
>         > context for scpuser.
>         > Oct 16 07:49:40 localhost sshd[20461]: fatal: SELinux
>         failure. Aborting
>         > connection.
>         >
>         > In permissive:
>         > Oct 16 07:55:59 localhost sshd[23302]: Accepted password for
>         scpuser from
>         > 192.168.1.1 port 56254 ssh2
>         > Oct 16 07:55:59 localhost sshd[23302]: error: Failed to get
>         default security
>         > context for scpuser.
>         > Oct 16 07:55:59 localhost sshd[23302]: error: SELinux
>         failure. Continuing in
>         > permissive mode.
>         >
>         > Could someone explain what these messages mean?
>         >
>         > I believe that I have a default context defined in the
>         "default context"
>         > file that should work. I believe I have an executable
>         context available for
>         > this user (using rbash rather than bash).
>         >
>         > How is sshd making this decision?  It looks like it is
>         calling setexeccon,
>         > but I'm not sure how that makes its decision.  Where should
>         I look for clues
>         > as to how to fix it?
>         >
>         >    Thank you,
>         >    Larry
>         >
>         
>         Did you add an entry to default_types?
>  
> I did.  And in default_contexts and in users/scpuser.  None of
> them fixed the issue.
> Could someone explain to me if these files are still used and what
> they are used for?  And if there are other files that might need to be
> modified as well?

Not up to date, but possibly still useful:
http://www.nsa.gov/research/_files/selinux/papers/policy2/x724.shtml
http://oss.tresys.com/projects/refpolicy/wiki/RoleCreation
 
> At this point it looks like I was missing a rule to allow the role
> transition, but it isn't quite fixed yet (and some of the entries in
> the files above may or not have been required as well).

-- 
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: sshd error: Failed to get default security context

[Larry Ross]

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

On Mon, Oct 19, 2009 at 6:53 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

>  On Sat, 2009-10-17 at 11:17 -0700, Larry Ross wrote:
> >
> >
> > On Sat, Oct 17, 2009 at 4:39 AM, Daniel J Walsh <dwalsh@redhat.com>
> > wrote:
> >
> >         On 10/16/2009 08:15 PM, Larry Ross wrote:
> >         > I have created a custom selinux user for the strict policy
> >         on RHEL5.3 who's
> >         > purpose is to connect via ssh and scp files off the
> >         machine.  When that user
> >         > tries to login via ssh, I see the following messages
> >         in /var/log/secure:
> >         >
> >         > In enforcing:
> >         > Oct 16 07:49:40 localhost sshd[20461]: Accepted password for
> >         scpuser
> >         > from 192.168.1.1 port 64680 ssh2
> >         > Oct 16 07:49:40 localhost sshd[20461]: error: Failed to get
> >         default security
> >         > context for scpuser.
> >         > Oct 16 07:49:40 localhost sshd[20461]: fatal: SELinux
> >         failure. Aborting
> >         > connection.
> >         >
> >         > In permissive:
> >         > Oct 16 07:55:59 localhost sshd[23302]: Accepted password for
> >         scpuser from
> >         > 192.168.1.1 port 56254 ssh2
> >         > Oct 16 07:55:59 localhost sshd[23302]: error: Failed to get
> >         default security
> >         > context for scpuser.
> >         > Oct 16 07:55:59 localhost sshd[23302]: error: SELinux
> >         failure. Continuing in
> >         > permissive mode.
> >         >
> >         > Could someone explain what these messages mean?
> >         >
> >         > I believe that I have a default context defined in the
> >         "default context"
> >         > file that should work. I believe I have an executable
> >         context available for
> >         > this user (using rbash rather than bash).
> >         >
> >         > How is sshd making this decision?  It looks like it is
> >         calling setexeccon,
> >         > but I'm not sure how that makes its decision.  Where should
> >         I look for clues
> >         > as to how to fix it?
> >         >
> >         >    Thank you,
> >         >    Larry
> >         >
> >
> >         Did you add an entry to default_types?
> >
> > I did.  And in default_contexts and in users/scpuser.  None of
> > them fixed the issue.
> > Could someone explain to me if these files are still used and what
> > they are used for?  And if there are other files that might need to be
> > modified as well?
>
> Not up to date, but possibly still useful:
> http://www.nsa.gov/research/_files/selinux/papers/policy2/x724.shtml
> http://oss.tresys.com/projects/refpolicy/wiki/RoleCreation
>

Stephen,
  Thank you for these links, I hadn't found them in my searching and they
seem to contain the information I need (and it looks like they are for the
most part still accurate).

  The missing piece is the MLS/MCS portion of the context, that seems to be
included in the files that came with RHEL5, is that used as any part of the
context decision?  Is it used when setting the new context?

  Thank you,
  Larry


>
> > At this point it looks like I was missing a rule to allow the role
> > transition, but it isn't quite fixed yet (and some of the entries in
> > the files above may or not have been required as well).
>
> --
> Stephen Smalley
> National Security Agency
>
>

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

Re: sshd error: Failed to get default security context

[Stephen Smalley]

On Mon, 2009-10-19 at 09:49 -0700, Larry Ross wrote:
> On Mon, Oct 19, 2009 at 6:53 AM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
>         
>         On Sat, 2009-10-17 at 11:17 -0700, Larry Ross wrote:
>         >
>         >
>         > On Sat, Oct 17, 2009 at 4:39 AM, Daniel J Walsh
>         <dwalsh@redhat.com>
>         > wrote:
>         >
>         >         On 10/16/2009 08:15 PM, Larry Ross wrote:
>         >         > I have created a custom selinux user for the
>         strict policy
>         >         on RHEL5.3 who's
>         >         > purpose is to connect via ssh and scp files off
>         the
>         >         machine.  When that user
>         >         > tries to login via ssh, I see the following
>         messages
>         >         in /var/log/secure:
>         >         >
>         >         > In enforcing:
>         >         > Oct 16 07:49:40 localhost sshd[20461]: Accepted
>         password for
>         >         scpuser
>         >         > from 192.168.1.1 port 64680 ssh2
>         >         > Oct 16 07:49:40 localhost sshd[20461]: error:
>         Failed to get
>         >         default security
>         >         > context for scpuser.
>         >         > Oct 16 07:49:40 localhost sshd[20461]: fatal:
>         SELinux
>         >         failure. Aborting
>         >         > connection.
>         >         >
>         >         > In permissive:
>         >         > Oct 16 07:55:59 localhost sshd[23302]: Accepted
>         password for
>         >         scpuser from
>         >         > 192.168.1.1 port 56254 ssh2
>         >         > Oct 16 07:55:59 localhost sshd[23302]: error:
>         Failed to get
>         >         default security
>         >         > context for scpuser.
>         >         > Oct 16 07:55:59 localhost sshd[23302]: error:
>         SELinux
>         >         failure. Continuing in
>         >         > permissive mode.
>         >         >
>         >         > Could someone explain what these messages mean?
>         >         >
>         >         > I believe that I have a default context defined in
>         the
>         >         "default context"
>         >         > file that should work. I believe I have an
>         executable
>         >         context available for
>         >         > this user (using rbash rather than bash).
>         >         >
>         >         > How is sshd making this decision?  It looks like
>         it is
>         >         calling setexeccon,
>         >         > but I'm not sure how that makes its decision.
>          Where should
>         >         I look for clues
>         >         > as to how to fix it?
>         >         >
>         >         >    Thank you,
>         >         >    Larry
>         >         >
>         >
>         >         Did you add an entry to default_types?
>         >
>         > I did.  And in default_contexts and in users/scpuser.  None
>         of
>         > them fixed the issue.
>         > Could someone explain to me if these files are still used
>         and what
>         > they are used for?  And if there are other files that might
>         need to be
>         > modified as well?
>         
>         
>         Not up to date, but possibly still useful:
>         http://www.nsa.gov/research/_files/selinux/papers/policy2/x724.shtml
>         http://oss.tresys.com/projects/refpolicy/wiki/RoleCreation
>  
> Stephen,
>   Thank you for these links, I hadn't found them in my searching and
> they seem to contain the information I need (and it looks like they
> are for the most part still accurate).
>  
>   The missing piece is the MLS/MCS portion of the context, that seems
> to be included in the files that came with RHEL5, is that used as any
> part of the context decision?  Is it used when setting the new
> context?

Not anymore, no - that is a legacy of the original MLS logic and
predates the use of the seusers configuration.  The MLS/MCS portion gets
set from the user's entry in the seusers configuration these days,
although it has to be within the authorized range for the corresponding
SELinux user in the policy of course.  LSPP configuration also has a
setup where sshd will try to preserve the level of the client when using
labeled networking, but that has to be enabled.

-- 
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: sshd error: Failed to get default security context

[Larry Ross]

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

On Mon, Oct 19, 2009 at 10:13 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

>  On Mon, 2009-10-19 at 09:49 -0700, Larry Ross wrote:
> > On Mon, Oct 19, 2009 at 6:53 AM, Stephen Smalley <sds@tycho.nsa.gov>
> > wrote:
> >
> >         On Sat, 2009-10-17 at 11:17 -0700, Larry Ross wrote:
> >         >
> >         >
> >         > On Sat, Oct 17, 2009 at 4:39 AM, Daniel J Walsh
> >         <dwalsh@redhat.com>
> >         > wrote:
> >         >
> >         >         On 10/16/2009 08:15 PM, Larry Ross wrote:
> >         >         > I have created a custom selinux user for the
> >         strict policy
> >         >         on RHEL5.3 who's
> >         >         > purpose is to connect via ssh and scp files off
> >         the
> >         >         machine.  When that user
> >         >         > tries to login via ssh, I see the following
> >         messages
> >         >         in /var/log/secure:
> >         >         >
> >         >         > In enforcing:
> >         >         > Oct 16 07:49:40 localhost sshd[20461]: Accepted
> >         password for
> >         >         scpuser
> >         >         > from 192.168.1.1 port 64680 ssh2
> >         >         > Oct 16 07:49:40 localhost sshd[20461]: error:
> >         Failed to get
> >         >         default security
> >         >         > context for scpuser.
> >         >         > Oct 16 07:49:40 localhost sshd[20461]: fatal:
> >         SELinux
> >         >         failure. Aborting
> >         >         > connection.
> >         >         >
> >         >         > In permissive:
> >         >         > Oct 16 07:55:59 localhost sshd[23302]: Accepted
> >         password for
> >         >         scpuser from
> >         >         > 192.168.1.1 port 56254 ssh2
> >         >         > Oct 16 07:55:59 localhost sshd[23302]: error:
> >         Failed to get
> >         >         default security
> >         >         > context for scpuser.
> >         >         > Oct 16 07:55:59 localhost sshd[23302]: error:
> >         SELinux
> >         >         failure. Continuing in
> >         >         > permissive mode.
> >         >         >
> >         >         > Could someone explain what these messages mean?
> >         >         >
> >         >         > I believe that I have a default context defined in
> >         the
> >         >         "default context"
> >         >         > file that should work. I believe I have an
> >         executable
> >         >         context available for
> >         >         > this user (using rbash rather than bash).
> >         >         >
> >         >         > How is sshd making this decision?  It looks like
> >         it is
> >         >         calling setexeccon,
> >         >         > but I'm not sure how that makes its decision.
> >          Where should
> >         >         I look for clues
> >         >         > as to how to fix it?
> >         >         >
> >         >         >    Thank you,
> >         >         >    Larry
> >         >         >
> >         >
> >         >         Did you add an entry to default_types?
> >         >
> >         > I did.  And in default_contexts and in users/scpuser.  None
> >         of
> >         > them fixed the issue.
> >         > Could someone explain to me if these files are still used
> >         and what
> >         > they are used for?  And if there are other files that might
> >         need to be
> >         > modified as well?
> >
> >
> >         Not up to date, but possibly still useful:
> >
> http://www.nsa.gov/research/_files/selinux/papers/policy2/x724.shtml
> >         http://oss.tresys.com/projects/refpolicy/wiki/RoleCreation
> >
> > Stephen,
> >   Thank you for these links, I hadn't found them in my searching and
> > they seem to contain the information I need (and it looks like they
> > are for the most part still accurate).
> >
> >   The missing piece is the MLS/MCS portion of the context, that seems
> > to be included in the files that came with RHEL5, is that used as any
> > part of the context decision?  Is it used when setting the new
> > context?
>
> Not anymore, no - that is a legacy of the original MLS logic and
> predates the use of the seusers configuration.  The MLS/MCS portion gets
> set from the user's entry in the seusers configuration these days,
> although it has to be within the authorized range for the corresponding
> SELinux user in the policy of course.  LSPP configuration also has a
> setup where sshd will try to preserve the level of the client when using
> labeled networking, but that has to be enabled.
>

Stephen,
  Thank you for your reply.  That was helpful.
  One question, what do you mean when you say "seusers configuration"?  Is
that the files in <policy type>/contexts/users or the information maintained
by semanage or something else?

  Thanks,
  Larry


>
> --
>  Stephen Smalley
> National Security Agency
>
>

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

Re: sshd error: Failed to get default security context

[Stephen Smalley]

On Mon, 2009-10-19 at 18:43 -0700, Larry Ross wrote:

> 
>   One question, what do you mean when you say "seusers configuration"?
> Is that the files in <policy type>/contexts/users or the information
> maintained by semanage or something else?

It is the information managed by semanage login, or by the User Mapping
tab of the system-config-selinux tool.  The configuration file
is /etc/selinux/$SELINUXTYPE/seusers.  It maps Linux usernames (logins)
to a (SELinux user identity, MLS/MCS range) pair.  Present in RHEL5, not
in RHEL4.

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

Where do I get a good Policy Base ?...

[Hasan Rezaul-CHR010]

Hi All,

I used to have the following SELinux related package versions on my
Linux (2.6.18) system:

Checkpolicy      - 1.33.1
Libselinux       - 2.0.13
Libsemanage      - 2.0.1
Libsepol         - 2.0.3
Libsetrans       - 0.1.18
Policycoreutils  - 2.0.16

And I used a 'strict' Base policy from Fedora Core 6. Made the
modifications I needed on top of that, and I was very happy...


We get our OS packaged/delivered from a third party company, and we're
upgrading to Linux 2.6.27, and as part of this upgrade, we are also
migrating to much newer versions of the SELinux packages. They are:

checkpolicy-2.0.19 
libselinux-2.0.85 
libsemanage-2.0.33 
libsepol-2.0.37 
policycoreutils-2.0.69 
sepolgen-1.0.17 


My questions are:

1. I believe the "strict" policy is no longer supported in the above
versions of SELinux packages? Is this true ?

2. The entire set of policies that I have fine-tuned over the years
under my  /etc/selinux/strict/modules/active/modules/*.pp  directory in
my previous older system, can I make any use of that ?? In other words,
can that stuff be re-used at all ? Or do I need to develop policy from
scratch again ?

3. What will be a good base policy for me to start policy development on
? Will it be refpolicy, or should I grab the base 'targeted' policy from
fedora core 11 for example ?

4. Assuming 'strict' is no longer supported in the NEW package versions
above, and I use a base 'targeted' policy as my starting point... Should
I be able to simply remove the "unconfined.pp" policy module from the
base targeted policy, and that essentially turns my system into
"strict-like" mode ? Is that advisable ?

5. If I do continue to use the 'targeted' base policy as is, how can I
develop policy on top of that, to make sure I still block specific
things that I don't want to take place. For example, I DON'T want a
user_t to be able to write to files of type  etc_t  for example. How do
I go about accomplishing this  given the 'targeted' framework ? I know
how to do this in the old 'strict' framework, not sure how to go about
it with the targeted framework. Please shed some light or point me to
documents...

Again, Any references or documentation links would be greatly
appreciated.

Thanks in advance.


--
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: Where do I get a good Policy Base ?...

[Dominick Grift]

On Mon, 2009-10-26 at 21:16 -0400, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I used to have the following SELinux related package versions on my
> Linux (2.6.18) system:
> 
> Checkpolicy      - 1.33.1
> Libselinux       - 2.0.13
> Libsemanage      - 2.0.1
> Libsepol         - 2.0.3
> Libsetrans       - 0.1.18
> Policycoreutils  - 2.0.16
> 
> And I used a 'strict' Base policy from Fedora Core 6. Made the
> modifications I needed on top of that, and I was very happy...
> 
> 
> We get our OS packaged/delivered from a third party company, and we're
> upgrading to Linux 2.6.27, and as part of this upgrade, we are also
> migrating to much newer versions of the SELinux packages. They are:
> 
> checkpolicy-2.0.19 
> libselinux-2.0.85 
> libsemanage-2.0.33 
> libsepol-2.0.37 
> policycoreutils-2.0.69 
> sepolgen-1.0.17 
> 
> 
> My questions are:
> 
> 1. I believe the "strict" policy is no longer supported in the above
> versions of SELinux packages? Is this true ?

the "strict" policy model is no longer supported. The strict and target
policy have merged to a policy model that is called "targeted". You can
configure the "targeted" policy to behave like old strict policy by
removing removing the unconfined modules and by mapping your Linux
logins to strict SELinux users.

> 
> 2. The entire set of policies that I have fine-tuned over the years
> under my  /etc/selinux/strict/modules/active/modules/*.pp  directory in
> my previous older system, can I make any use of that ?? In other words,
> can that stuff be re-used at all ? Or do I need to develop policy from
> scratch again ?

I am not sure about this but my opinion is that it should  in most cases
be possible to use older binary modules in newer policy. Reference
policy should be compatible in my view.

Please note though that is encouraged to keep the source policy for your
binary modules so that you can edit policy modules easily later.
> 
> 3. What will be a good base policy for me to start policy development on
> ? Will it be refpolicy, or should I grab the base 'targeted' policy from
> fedora core 11 for example ?

This depends on your distro, but generally you should be better of with
a distro specific policy. Also keep in mind that Fedora has a active
community, frequent updates and many testers.

> 
> 4. Assuming 'strict' is no longer supported in the NEW package versions
> above, and I use a base 'targeted' policy as my starting point... Should
> I be able to simply remove the "unconfined.pp" policy module from the
> base targeted policy, and that essentially turns my system into
> "strict-like" mode ? Is that advisable ?

That is the idea, yes,

> 
> 5. If I do continue to use the 'targeted' base policy as is, how can I
> develop policy on top of that, to make sure I still block specific
> things that I don't want to take place. For example, I DON'T want a
> user_t to be able to write to files of type  etc_t  for example. How do
> I go about accomplishing this  given the 'targeted' framework ? I know
> how to do this in the old 'strict' framework, not sure how to go about
> it with the targeted framework. Please shed some light or point me to
> documents...

You can write your own custom policy modules on that of the policy that
is distributed. Current policy is usually modular. Basically write a
source policy module, build it and install it using the semanage or the
semodule command.

e.g. (Fedora/RedHat):

echo "policy_module(mytest, 0.0.1)" > mytest.te;
make -f /usr/share/selinux/devel/Makefile mytest.pp;
sudo semodule -i mytest.pp
sudo semodule -l | grep mytest

> 
> Again, Any references or documentation links would be greatly
> appreciated.

www.selinuxproject.org/page/User_Resources
> 
> Thanks in advance.
> 
> 
> --
> 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.



--
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: Where do I get a good Policy Base ?...

[Christopher J. PeBenito]

On Tue, 2009-10-27 at 09:49 +0100, Dominick Grift wrote:
> On Mon, 2009-10-26 at 21:16 -0400, Hasan Rezaul-CHR010 wrote:
> > Hi All,
> > 
> > I used to have the following SELinux related package versions on my
> > Linux (2.6.18) system:
[...]
> > And I used a 'strict' Base policy from Fedora Core 6. Made the
> > modifications I needed on top of that, and I was very happy...
> > 
> > 
> > We get our OS packaged/delivered from a third party company, and we're
> > upgrading to Linux 2.6.27, and as part of this upgrade, we are also
> > migrating to much newer versions of the SELinux packages. They are:
[...]
> > My questions are:
> > 
> > 1. I believe the "strict" policy is no longer supported in the above
> > versions of SELinux packages? Is this true ?
> 
> the "strict" policy model is no longer supported. The strict and target
> policy have merged to a policy model that is called "targeted".

No, it doesn't have a specific name.  However, for ease of discussion, a
system with all confined domains is still referred to as "strict",
otherwise its "targeted".


> > 2. The entire set of policies that I have fine-tuned over the years
> > under my  /etc/selinux/strict/modules/active/modules/*.pp  directory in
> > my previous older system, can I make any use of that ?? In other words,
> > can that stuff be re-used at all ? Or do I need to develop policy from
> > scratch again ?
> 
> I am not sure about this but my opinion is that it should  in most cases
> be possible to use older binary modules in newer policy. Reference
> policy should be compatible in my view.

We try hard to maintain compatibility, but FC6 is several years old, so
compatibility may have been broken, especially after the 2.x API break
for UBAC.


-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: Where do I get a good Policy Base ?...

[Hasan Rezaul-CHR010]

Thanks for your answers   :-)

A quick follow up question...

What would be the most appropriate Fedora selinux-policy that I can
start off with as a base to build on top of, Given:

that I have Linux 2.6.27,  and I have the following latest SELinux
package versions :

> checkpolicy-2.0.19
> libselinux-2.0.85
> libsemanage-2.0.33
> libsepol-2.0.37
> policycoreutils-2.0.69
> sepolgen-1.0.17

Should I use Fedora 11 -   
download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages
/selinux-policy-3.6.6-5.fc11.noarch.rpm

Or should I use Fedora 10 - 
download.fedora.redhat.com/pub/fedora/linux/updates/10/i386/selinux-poli
cy-3.5.13-45.fc10.noarch.rpm

Or should I use new RefPolicy from OpenSuSE -
ftp5.gwdg.de/pub/opensuse/repositories/security:/SELinux/openSUSE_Factor
y/noarch/selinux-policy-refpolicy-standard-2.20081210-1.8.noarch.rpm


Thanks in advance as usual for all your help.


-----Original Message-----
From: Dominick Grift [mailto:domg472@gmail.com] 
Sent: Tuesday, October 27, 2009 3:50 AM
To: Hasan Rezaul-CHR010
Cc: selinux@tycho.nsa.gov
Subject: Re: Where do I get a good Policy Base ?...

On Mon, 2009-10-26 at 21:16 -0400, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I used to have the following SELinux related package versions on my 
> Linux (2.6.18) system:
> 
> Checkpolicy      - 1.33.1
> Libselinux       - 2.0.13
> Libsemanage      - 2.0.1
> Libsepol         - 2.0.3
> Libsetrans       - 0.1.18
> Policycoreutils  - 2.0.16
> 
> And I used a 'strict' Base policy from Fedora Core 6. Made the 
> modifications I needed on top of that, and I was very happy...
> 
> 
> We get our OS packaged/delivered from a third party company, and we're

> upgrading to Linux 2.6.27, and as part of this upgrade, we are also 
> migrating to much newer versions of the SELinux packages. They are:
> 
> checkpolicy-2.0.19
> libselinux-2.0.85
> libsemanage-2.0.33
> libsepol-2.0.37
> policycoreutils-2.0.69
> sepolgen-1.0.17
> 
> 
> My questions are:
> 
> 1. I believe the "strict" policy is no longer supported in the above 
> versions of SELinux packages? Is this true ?

the "strict" policy model is no longer supported. The strict and target
policy have merged to a policy model that is called "targeted". You can
configure the "targeted" policy to behave like old strict policy by
removing removing the unconfined modules and by mapping your Linux
logins to strict SELinux users.

> 
> 2. The entire set of policies that I have fine-tuned over the years 
> under my  /etc/selinux/strict/modules/active/modules/*.pp  directory 
> in my previous older system, can I make any use of that ?? In other 
> words, can that stuff be re-used at all ? Or do I need to develop 
> policy from scratch again ?

I am not sure about this but my opinion is that it should  in most cases
be possible to use older binary modules in newer policy. Reference
policy should be compatible in my view.

Please note though that is encouraged to keep the source policy for your
binary modules so that you can edit policy modules easily later.
> 
> 3. What will be a good base policy for me to start policy development 
> on ? Will it be refpolicy, or should I grab the base 'targeted' policy

> from fedora core 11 for example ?

This depends on your distro, but generally you should be better of with
a distro specific policy. Also keep in mind that Fedora has a active
community, frequent updates and many testers.

> 
> 4. Assuming 'strict' is no longer supported in the NEW package 
> versions above, and I use a base 'targeted' policy as my starting 
> point... Should I be able to simply remove the "unconfined.pp" policy 
> module from the base targeted policy, and that essentially turns my 
> system into "strict-like" mode ? Is that advisable ?

That is the idea, yes,

> 
> 5. If I do continue to use the 'targeted' base policy as is, how can I

> develop policy on top of that, to make sure I still block specific 
> things that I don't want to take place. For example, I DON'T want a 
> user_t to be able to write to files of type  etc_t  for example. How 
> do I go about accomplishing this  given the 'targeted' framework ? I 
> know how to do this in the old 'strict' framework, not sure how to go 
> about it with the targeted framework. Please shed some light or point 
> me to documents...

You can write your own custom policy modules on that of the policy that
is distributed. Current policy is usually modular. Basically write a
source policy module, build it and install it using the semanage or the
semodule command.

e.g. (Fedora/RedHat):

echo "policy_module(mytest, 0.0.1)" > mytest.te; make -f
/usr/share/selinux/devel/Makefile mytest.pp; sudo semodule -i mytest.pp
sudo semodule -l | grep mytest

> 
> Again, Any references or documentation links would be greatly 
> appreciated.

www.selinuxproject.org/page/User_Resources
> 
> Thanks in advance.
> 
> 
> --
> 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.




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

How to use sepolgen VS. policygentool

[Hasan Rezaul-CHR010]

 
Hi All,

I used to have the following SELinux related package versions on my
Linux (2.6.18) system:
 
checkpolicy      - 1.33.1
libselinux       - 2.0.13
libsemanage      - 2.0.1
libsepol         - 2.0.3
libsetrans       - 0.1.18
policycoreutils  - 2.0.16
 
On that machine, I used to use  /usr/share/selinux/devel/policygentool
to create new custom policy templates, and modified them as necessary,
and used to run

 make -f /usr/share/selinux/devel/Makefile  to compile my  custom.te
policies to create custom.pp.

I now have upgraded to Linux 2.6.27 on a non-popular Linux distro, and
as part of this upgrade, we also migrated to much newer versions of the
SELinux packages. They are:
 
 checkpolicy-2.0.19
 libselinux-2.0.85
 libsemanage-2.0.33
 libsepol-2.0.37
 policycoreutils-2.0.69
 sepolgen-1.0.17

My questions are :

1. On this new system, I don't see policygentool anymore ! Infact, I am
missing the whole  /usr/share/selinux/devel/* directory.  Can I install
the  selinux-policy-devel  package on this machine ? If so, where should
I get it from ? Is policygentool still supported ?

2. I do see this new package "sepolgen", which I am guessing is the
newer replacement ? I do see that sepolgen is infact installed on my
system:

	root@unknown:/root> rpm -q sepolgen
	sepolgen-1.0.17-1_WR3.0.2as.ppc_e500v2
	root@unknown:/root>
	root@unknown:/root> which sepolgen
	which: no sepolgen in
(/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/bin)
	root@unknown:/root>
	root@unknown:/root>
	root@unknown:/root> cd /usr/lib/sepolgen/
	root@unknown:/usr/lib/sepolgen> ls
	perm_map
	root@unknown:/usr/lib/sepolgen>

How do I use this sepolgen thing ?  I thought I could run an sepolgen
executable as follows: "sepolgen -t <program>"
But I don't see where the sepolgen executable is ??? Do I need to
install any other packages to use sepolgen ?

3. Finally, it seems that sepolgen will create a template policy based
on a particular process, e.g. /usr/bin/ssh

   What if I wanted to write more generic policy for restricting selinux
users. For example:

   neverallow user_t etc_t:file write;
   neverallow user_t bin_t:file write;
   neverallow user_t proc_t:file write;
   neverallow staff_t bin_t:file write;
   :
   :

   what <program_name> should I supply in the sepolgen command, to
create a custom policy template for this purpose ?


Thanks in advance for all your help  :-)
   


--
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: How to use sepolgen VS. policygentool

[Hasan Rezaul-CHR010]

One more question...

Lets say I used audit2allow to create a custom policy as follows:

  cat deny.log | audit2allow -M test
  -- this will create test.te, and test.pp for me

If I wanted to make additional modifications to test.te, how can I
compile this new test.te to come up with the new test.pp ??

Note: I don't seem to have the  /usr/share/selinux/devel/Makefile  file
present on my setup !?! Is there some alternative way to compile the
*.te  files ??  Thanks.

 

-----Original Message-----
From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
On Behalf Of Hasan Rezaul-CHR010
Sent: Wednesday, December 09, 2009 8:18 PM
To: Daniel J Walsh
Cc: selinux@tycho.nsa.gov
Subject: How to use sepolgen VS. policygentool

 
Hi All,

I used to have the following SELinux related package versions on my
Linux (2.6.18) system:
 
checkpolicy      - 1.33.1
libselinux       - 2.0.13
libsemanage      - 2.0.1
libsepol         - 2.0.3
libsetrans       - 0.1.18
policycoreutils  - 2.0.16
 
On that machine, I used to use  /usr/share/selinux/devel/policygentool
to create new custom policy templates, and modified them as necessary,
and used to run

 make -f /usr/share/selinux/devel/Makefile  to compile my  custom.te
policies to create custom.pp.

I now have upgraded to Linux 2.6.27 on a non-popular Linux distro, and
as part of this upgrade, we also migrated to much newer versions of the
SELinux packages. They are:
 
 checkpolicy-2.0.19
 libselinux-2.0.85
 libsemanage-2.0.33
 libsepol-2.0.37
 policycoreutils-2.0.69
 sepolgen-1.0.17

My questions are :

1. On this new system, I don't see policygentool anymore ! Infact, I am
missing the whole  /usr/share/selinux/devel/* directory.  Can I install
the  selinux-policy-devel  package on this machine ? If so, where should
I get it from ? Is policygentool still supported ?

2. I do see this new package "sepolgen", which I am guessing is the
newer replacement ? I do see that sepolgen is infact installed on my
system:

	root@unknown:/root> rpm -q sepolgen
	sepolgen-1.0.17-1_WR3.0.2as.ppc_e500v2
	root@unknown:/root>
	root@unknown:/root> which sepolgen
	which: no sepolgen in
(/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/bin)
	root@unknown:/root>
	root@unknown:/root>
	root@unknown:/root> cd /usr/lib/sepolgen/
	root@unknown:/usr/lib/sepolgen> ls
	perm_map
	root@unknown:/usr/lib/sepolgen>

How do I use this sepolgen thing ?  I thought I could run an sepolgen
executable as follows: "sepolgen -t <program>"
But I don't see where the sepolgen executable is ??? Do I need to
install any other packages to use sepolgen ?

3. Finally, it seems that sepolgen will create a template policy based
on a particular process, e.g. /usr/bin/ssh

   What if I wanted to write more generic policy for restricting selinux
users. For example:

   neverallow user_t etc_t:file write;
   neverallow user_t bin_t:file write;
   neverallow user_t proc_t:file write;
   neverallow staff_t bin_t:file write;
   :
   :

   what <program_name> should I supply in the sepolgen command, to
create a custom policy template for this purpose ?


Thanks in advance for all your help  :-)
   


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


--
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: How to use sepolgen VS. policygentool

[Stephen Smalley]

On Wed, 2009-12-09 at 21:50 -0500, Hasan Rezaul-CHR010 wrote:
> One more question...
> 
> Lets say I used audit2allow to create a custom policy as follows:
> 
>   cat deny.log | audit2allow -M test
>   -- this will create test.te, and test.pp for me
> 
> If I wanted to make additional modifications to test.te, how can I
> compile this new test.te to come up with the new test.pp ??
> 
> Note: I don't seem to have the  /usr/share/selinux/devel/Makefile  file
> present on my setup !?! Is there some alternative way to compile the
> *.te  files ??  Thanks.

Same sequence of commands that are run by audit2allow or the Makefile:
checkmodule -M -m test.te -o test.mod
semodule_package -o test.pp -m test.mod

-- 
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: How to use sepolgen VS. policygentool

[Guido Trentalancia]

You can compile the policy module as follows in two steps:

checkmodule -M -m mymodule.te -o mymodule.mod
semodule_package -o mymodule.pp -m mymodule.mod

semodule_package also accepts the optional "-f" parameter for specifying
file contexts.

However, I recommend that you use the Makefile provided
in /usr/share/selinux/devel and /usr/share/selinux/include.

You don't specify which distribution you are using. Just refer to your
distribution packager for further information on how to get the full
SELinux development tree mentioned above.

I hope this helps (it should answer both of your messages).

Regards,

Guido

On Wed, 2009-12-09 at 21:50 -0500, Hasan Rezaul-CHR010 wrote:
> One more question...
> 
> Lets say I used audit2allow to create a custom policy as follows:
> 
>   cat deny.log | audit2allow -M test
>   -- this will create test.te, and test.pp for me
> 
> If I wanted to make additional modifications to test.te, how can I
> compile this new test.te to come up with the new test.pp ??
> 
> Note: I don't seem to have the  /usr/share/selinux/devel/Makefile  file
> present on my setup !?! Is there some alternative way to compile the
> *.te  files ??  Thanks.
> 
>  
> 
> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
> On Behalf Of Hasan Rezaul-CHR010
> Sent: Wednesday, December 09, 2009 8:18 PM
> To: Daniel J Walsh
> Cc: selinux@tycho.nsa.gov
> Subject: How to use sepolgen VS. policygentool
> 
>  
> Hi All,
> 
> I used to have the following SELinux related package versions on my
> Linux (2.6.18) system:
>  
> checkpolicy      - 1.33.1
> libselinux       - 2.0.13
> libsemanage      - 2.0.1
> libsepol         - 2.0.3
> libsetrans       - 0.1.18
> policycoreutils  - 2.0.16
>  
> On that machine, I used to use  /usr/share/selinux/devel/policygentool
> to create new custom policy templates, and modified them as necessary,
> and used to run
> 
>  make -f /usr/share/selinux/devel/Makefile  to compile my  custom.te
> policies to create custom.pp.
> 
> I now have upgraded to Linux 2.6.27 on a non-popular Linux distro, and
> as part of this upgrade, we also migrated to much newer versions of the
> SELinux packages. They are:
>  
>  checkpolicy-2.0.19
>  libselinux-2.0.85
>  libsemanage-2.0.33
>  libsepol-2.0.37
>  policycoreutils-2.0.69
>  sepolgen-1.0.17
> 
> My questions are :
> 
> 1. On this new system, I don't see policygentool anymore ! Infact, I am
> missing the whole  /usr/share/selinux/devel/* directory.  Can I install
> the  selinux-policy-devel  package on this machine ? If so, where should
> I get it from ? Is policygentool still supported ?
> 
> 2. I do see this new package "sepolgen", which I am guessing is the
> newer replacement ? I do see that sepolgen is infact installed on my
> system:
> 
> 	root@unknown:/root> rpm -q sepolgen
> 	sepolgen-1.0.17-1_WR3.0.2as.ppc_e500v2
> 	root@unknown:/root>
> 	root@unknown:/root> which sepolgen
> 	which: no sepolgen in
> (/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/bin)
> 	root@unknown:/root>
> 	root@unknown:/root>
> 	root@unknown:/root> cd /usr/lib/sepolgen/
> 	root@unknown:/usr/lib/sepolgen> ls
> 	perm_map
> 	root@unknown:/usr/lib/sepolgen>
> 
> How do I use this sepolgen thing ?  I thought I could run an sepolgen
> executable as follows: "sepolgen -t <program>"
> But I don't see where the sepolgen executable is ??? Do I need to
> install any other packages to use sepolgen ?
> 
> 3. Finally, it seems that sepolgen will create a template policy based
> on a particular process, e.g. /usr/bin/ssh
> 
>    What if I wanted to write more generic policy for restricting selinux
> users. For example:
> 
>    neverallow user_t etc_t:file write;
>    neverallow user_t bin_t:file write;
>    neverallow user_t proc_t:file write;
>    neverallow staff_t bin_t:file write;
>    :
>    :
> 
>    what <program_name> should I supply in the sepolgen command, to
> create a custom policy template for this purpose ?
> 
> 
> Thanks in advance for all your help  :-)
>    
> 
> 
> --
> 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.
> 
> 
> --
> 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.
> 



--
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: How to use sepolgen VS. policygentool

[Daniel J Walsh]

On 12/09/2009 09:50 PM, Hasan Rezaul-CHR010 wrote:
> One more question...
> 
> Lets say I used audit2allow to create a custom policy as follows:
> 
>   cat deny.log | audit2allow -M test
>   -- this will create test.te, and test.pp for me
> 
> If I wanted to make additional modifications to test.te, how can I
> compile this new test.te to come up with the new test.pp ??
> 
> Note: I don't seem to have the  /usr/share/selinux/devel/Makefile  file
> present on my setup !?! Is there some alternative way to compile the
> *.te  files ??  Thanks.
> 
>  
> 
> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
> On Behalf Of Hasan Rezaul-CHR010
> Sent: Wednesday, December 09, 2009 8:18 PM
> To: Daniel J Walsh
> Cc: selinux@tycho.nsa.gov
> Subject: How to use sepolgen VS. policygentool
> 
>  
> Hi All,
> 
> I used to have the following SELinux related package versions on my
> Linux (2.6.18) system:
>  
> checkpolicy      - 1.33.1
> libselinux       - 2.0.13
> libsemanage      - 2.0.1
> libsepol         - 2.0.3
> libsetrans       - 0.1.18
> policycoreutils  - 2.0.16
>  
> On that machine, I used to use  /usr/share/selinux/devel/policygentool
> to create new custom policy templates, and modified them as necessary,
> and used to run
> 
>  make -f /usr/share/selinux/devel/Makefile  to compile my  custom.te
> policies to create custom.pp.
> 
> I now have upgraded to Linux 2.6.27 on a non-popular Linux distro, and
> as part of this upgrade, we also migrated to much newer versions of the
> SELinux packages. They are:
>  
>  checkpolicy-2.0.19
>  libselinux-2.0.85
>  libsemanage-2.0.33
>  libsepol-2.0.37
>  policycoreutils-2.0.69
>  sepolgen-1.0.17
> 
> My questions are :
> 
> 1. On this new system, I don't see policygentool anymore ! Infact, I am
> missing the whole  /usr/share/selinux/devel/* directory.  Can I install
> the  selinux-policy-devel  package on this machine ? If so, where should
> I get it from ? Is policygentool still supported ?
> 
> 2. I do see this new package "sepolgen", which I am guessing is the
> newer replacement ? I do see that sepolgen is infact installed on my
> system:
> 
> 	root@unknown:/root> rpm -q sepolgen
> 	sepolgen-1.0.17-1_WR3.0.2as.ppc_e500v2
> 	root@unknown:/root>
> 	root@unknown:/root> which sepolgen
> 	which: no sepolgen in
> (/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/bin)
> 	root@unknown:/root>
> 	root@unknown:/root>
> 	root@unknown:/root> cd /usr/lib/sepolgen/
> 	root@unknown:/usr/lib/sepolgen> ls
> 	perm_map
> 	root@unknown:/usr/lib/sepolgen>
> 
> How do I use this sepolgen thing ?  I thought I could run an sepolgen
> executable as follows: "sepolgen -t <program>"
> But I don't see where the sepolgen executable is ??? Do I need to
> install any other packages to use sepolgen ?
> 
> 3. Finally, it seems that sepolgen will create a template policy based
> on a particular process, e.g. /usr/bin/ssh
> 
>    What if I wanted to write more generic policy for restricting selinux
> users. For example:
> 
>    neverallow user_t etc_t:file write;
>    neverallow user_t bin_t:file write;
>    neverallow user_t proc_t:file write;
>    neverallow staff_t bin_t:file write;
>    :
>    :
> 
>    what <program_name> should I supply in the sepolgen command, to
> create a custom policy template for this purpose ?
> 
> 
> Thanks in advance for all your help  :-)
>    
> 
> 
> --
> 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.

Something like.

checkmodule -M -m mypol.te  -o mypol.mod
semodule_package -m mypol.mod -f mypol.fc -o mypol.pp


--
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: How to use sepolgen VS. policygentool

[Stephen Smalley]

On Wed, 2009-12-09 at 21:18 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I used to have the following SELinux related package versions on my
> Linux (2.6.18) system:
>  
> checkpolicy      - 1.33.1
> libselinux       - 2.0.13
> libsemanage      - 2.0.1
> libsepol         - 2.0.3
> libsetrans       - 0.1.18
> policycoreutils  - 2.0.16
>  
> On that machine, I used to use  /usr/share/selinux/devel/policygentool
> to create new custom policy templates, and modified them as necessary,
> and used to run
> 
>  make -f /usr/share/selinux/devel/Makefile  to compile my  custom.te
> policies to create custom.pp.
> 
> I now have upgraded to Linux 2.6.27 on a non-popular Linux distro, and
> as part of this upgrade, we also migrated to much newer versions of the
> SELinux packages. They are:
>  
>  checkpolicy-2.0.19
>  libselinux-2.0.85
>  libsemanage-2.0.33
>  libsepol-2.0.37
>  policycoreutils-2.0.69
>  sepolgen-1.0.17
> 
> My questions are :
> 
> 1. On this new system, I don't see policygentool anymore ! Infact, I am
> missing the whole  /usr/share/selinux/devel/* directory.  Can I install
> the  selinux-policy-devel  package on this machine ? If so, where should
> I get it from ? Is policygentool still supported ?

policygentool and /usr/share/selinux/devel/ is specific to Fedora and
RHEL - it isn't part of upstream SELinux or reference policy AFAIK.  I
think reference policy puts its headers
under /usr/share/selinux/$POLICYTYPE so that you can have multiple sets
of headers.

> 2. I do see this new package "sepolgen", which I am guessing is the
> newer replacement ? I do see that sepolgen is infact installed on my
> system:

No, sepolgen is a python module that provides the core logic for
audit2allow.  Not related to policygentool at all.

> 	root@unknown:/root> rpm -q sepolgen
> 	sepolgen-1.0.17-1_WR3.0.2as.ppc_e500v2
> 	root@unknown:/root>
> 	root@unknown:/root> which sepolgen
> 	which: no sepolgen in
> (/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/bin)
> 	root@unknown:/root>
> 	root@unknown:/root>
> 	root@unknown:/root> cd /usr/lib/sepolgen/
> 	root@unknown:/usr/lib/sepolgen> ls
> 	perm_map
> 	root@unknown:/usr/lib/sepolgen>
> 
> How do I use this sepolgen thing ?  I thought I could run an sepolgen
> executable as follows: "sepolgen -t <program>"
> But I don't see where the sepolgen executable is ??? Do I need to
> install any other packages to use sepolgen ?
> 
> 3. Finally, it seems that sepolgen will create a template policy based
> on a particular process, e.g. /usr/bin/ssh
> 
>    What if I wanted to write more generic policy for restricting selinux
> users. For example:
> 
>    neverallow user_t etc_t:file write;
>    neverallow user_t bin_t:file write;
>    neverallow user_t proc_t:file write;
>    neverallow staff_t bin_t:file write;
>    :
>    :
> 
>    what <program_name> should I supply in the sepolgen command, to
> create a custom policy template for this purpose ?
> 
> 
> Thanks in advance for all your help  :-)
>    
> 
> 
> --
> 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.
-- 
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: How to use sepolgen VS. policygentool

[Daniel J Walsh]

On 12/10/2009 10:54 AM, Stephen Smalley wrote:
> On Wed, 2009-12-09 at 21:18 -0500, Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I used to have the following SELinux related package versions on my
>> Linux (2.6.18) system:
>>  
>> checkpolicy      - 1.33.1
>> libselinux       - 2.0.13
>> libsemanage      - 2.0.1
>> libsepol         - 2.0.3
>> libsetrans       - 0.1.18
>> policycoreutils  - 2.0.16
>>  
>> On that machine, I used to use  /usr/share/selinux/devel/policygentool
>> to create new custom policy templates, and modified them as necessary,
>> and used to run
>>
>>  make -f /usr/share/selinux/devel/Makefile  to compile my  custom.te
>> policies to create custom.pp.
>>
>> I now have upgraded to Linux 2.6.27 on a non-popular Linux distro, and
>> as part of this upgrade, we also migrated to much newer versions of the
>> SELinux packages. They are:
>>  
>>  checkpolicy-2.0.19
>>  libselinux-2.0.85
>>  libsemanage-2.0.33
>>  libsepol-2.0.37
>>  policycoreutils-2.0.69
>>  sepolgen-1.0.17
>>
>> My questions are :
>>
>> 1. On this new system, I don't see policygentool anymore ! Infact, I am
>> missing the whole  /usr/share/selinux/devel/* directory.  Can I install
>> the  selinux-policy-devel  package on this machine ? If so, where should
>> I get it from ? Is policygentool still supported ?
> 
> policygentool and /usr/share/selinux/devel/ is specific to Fedora and
> RHEL - it isn't part of upstream SELinux or reference policy AFAIK.  I
> think reference policy puts its headers
> under /usr/share/selinux/$POLICYTYPE so that you can have multiple sets
> of headers.
> 
>> 2. I do see this new package "sepolgen", which I am guessing is the
>> newer replacement ? I do see that sepolgen is infact installed on my
>> system:
> 
> No, sepolgen is a python module that provides the core logic for
> audit2allow.  Not related to policygentool at all.
> 
>> 	root@unknown:/root> rpm -q sepolgen
>> 	sepolgen-1.0.17-1_WR3.0.2as.ppc_e500v2
>> 	root@unknown:/root>
>> 	root@unknown:/root> which sepolgen
>> 	which: no sepolgen in
>> (/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/bin)
>> 	root@unknown:/root>
>> 	root@unknown:/root>
>> 	root@unknown:/root> cd /usr/lib/sepolgen/
>> 	root@unknown:/usr/lib/sepolgen> ls
>> 	perm_map
>> 	root@unknown:/usr/lib/sepolgen>
>>
>> How do I use this sepolgen thing ?  I thought I could run an sepolgen
>> executable as follows: "sepolgen -t <program>"
>> But I don't see where the sepolgen executable is ??? Do I need to
>> install any other packages to use sepolgen ?
>>
>> 3. Finally, it seems that sepolgen will create a template policy based
>> on a particular process, e.g. /usr/bin/ssh
>>
>>    What if I wanted to write more generic policy for restricting selinux
>> users. For example:
>>
>>    neverallow user_t etc_t:file write;
>>    neverallow user_t bin_t:file write;
>>    neverallow user_t proc_t:file write;
>>    neverallow staff_t bin_t:file write;
>>    :
>>    :
>>
>>    what <program_name> should I supply in the sepolgen command, to
>> create a custom policy template for this purpose ?
>>
>>
>> Thanks in advance for all your help  :-)
>>    
>>
>>
>> --
>> 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.
I have added a command line tool sepolgen which uses the polgengui stuff to generate policy.

http://danwalsh.livejournal.com/32430.html

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

[Hasan Rezaul-CHR010]

Hi All,

I have Linux 2.6.27 on a non-popular Linux distro, and I have the
following SELinux package versions :
  
>  checkpolicy-2.0.19
>  libselinux-2.0.85
>  libsemanage-2.0.33
>  libsepol-2.0.37
>  policycoreutils-2.0.69
>  sepolgen-1.0.17

I know SELinux's is governing framework is that by default everything is
DENIED, except all accesses that are explicitly allowed in the policy...

Is there anyway whatsoever to reverse that philosophy ?  In other words,
is it possible to configure things and write policy in a way such that:

Only explicit things are disallowed... So whenever no explicit policy
exists for an access request it is actually ALLOWED. This way, if I
write a new task or process, I don't have to write new policy for it to
allow all the things it needs. By default things will just be allowed,
unless some of those accesses have been explicitly disallowed in policy
?

My guess is that this CANT be done... But thought I would ask anyway ?

Also can SELinux mappings be created for a Unix Group, as opposed to
mapping to individual Linux Users ?

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

[Dominick Grift]

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

On Tue, Dec 15, 2009 at 12:43:37PM -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I have Linux 2.6.27 on a non-popular Linux distro, and I have the
> following SELinux package versions :
>   
> >  checkpolicy-2.0.19
> >  libselinux-2.0.85
> >  libsemanage-2.0.33
> >  libsepol-2.0.37
> >  policycoreutils-2.0.69
> >  sepolgen-1.0.17
> 
> I know SELinux's is governing framework is that by default everything is
> DENIED, except all accesses that are explicitly allowed in the policy...
> 
> Is there anyway whatsoever to reverse that philosophy ?  In other words,
> is it possible to configure things and write policy in a way such that:
> 
> Only explicit things are disallowed... So whenever no explicit policy
> exists for an access request it is actually ALLOWED. This way, if I
> write a new task or process, I don't have to write new policy for it to
> allow all the things it needs. By default things will just be allowed,
> unless some of those accesses have been explicitly disallowed in policy
> ?
> 
> My guess is that this CANT be done... But thought I would ask anyway ?

Fedoras' selinux-policy-minimal is supposed to be just that (well kind of). By default everything runs in a unconfined domain which is allowed all access. To restrict processes you should explicitly write policy. 
> 
> Also can SELinux mappings be created for a Unix Group, as opposed to
> mapping to individual Linux Users ?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Policy writing philosophy...

[Bandan Das]

On Tue, 2009-12-15 at 12:43 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I have Linux 2.6.27 on a non-popular Linux distro, and I have the
> following SELinux package versions :
>   
> >  checkpolicy-2.0.19
> >  libselinux-2.0.85
> >  libsemanage-2.0.33
> >  libsepol-2.0.37
> >  policycoreutils-2.0.69
> >  sepolgen-1.0.17
> 
> I know SELinux's is governing framework is that by default everything
> is
> DENIED, except all accesses that are explicitly allowed in the
> policy...
> 
> Is there anyway whatsoever to reverse that philosophy ?  In other
> words,
> is it possible to configure things and write policy in a way such
> that:
> 
> Only explicit things are disallowed... So whenever no explicit policy
> exists for an access request it is actually ALLOWED. This way, if I
> write a new task or process, I don't have to write new policy for it
> to
> allow all the things it needs. By default things will just be allowed,
> unless some of those accesses have been explicitly disallowed in
> policy
> ?
> 
> My guess is that this CANT be done... But thought I would ask anyway ?

If you are asking whether SELinux can be used to configure a set of
"disablities" rather than "capabilites", I guess the answer would be no.
The reason is the question itself :) It's a different design
philosophy..

Bandan

> Also can SELinux mappings be created for a Unix Group, as opposed to
> mapping to individual Linux Users ?
> 
> 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.



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

[Stephen Smalley]

On Tue, 2009-12-15 at 12:43 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I have Linux 2.6.27 on a non-popular Linux distro, and I have the
> following SELinux package versions :
>   
> >  checkpolicy-2.0.19
> >  libselinux-2.0.85
> >  libsemanage-2.0.33
> >  libsepol-2.0.37
> >  policycoreutils-2.0.69
> >  sepolgen-1.0.17
> 
> I know SELinux's is governing framework is that by default everything is
> DENIED, except all accesses that are explicitly allowed in the policy...
> 
> Is there anyway whatsoever to reverse that philosophy ?  In other words,
> is it possible to configure things and write policy in a way such that:
> 
> Only explicit things are disallowed... So whenever no explicit policy
> exists for an access request it is actually ALLOWED. This way, if I
> write a new task or process, I don't have to write new policy for it to
> allow all the things it needs. By default things will just be allowed,
> unless some of those accesses have been explicitly disallowed in policy
> ?
> 
> My guess is that this CANT be done... But thought I would ask anyway ?

Not from a mechanism point of view, no.  But from a policy point of
view, you can achieve your end by initially declaring a domain as an
unconfined domain and then removing rules, or by declaring a domain as a
permissive domain and generating rules for it via audit2allow.

> Also can SELinux mappings be created for a Unix Group, as opposed to
> mapping to individual Linux Users ?

Yes - just use %groupname in the seusers configuration.

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

[Hasan Rezaul-CHR010]

Thanks as always Stephen. 

>> Also can SELinux mappings be created for a Unix Group, as opposed to 
>> mapping to individual Linux Users ?

> Yes - just use %groupname in the seusers configuration.

Would you kindly give me some more details / examples, or point me to a
URL or document that I can learn more about how to achieve this ?
Thanks again.

Also, I have a Fedora 12 machine now. I was wondering, where can I get
all the  ***.te  files for the corresponding ***.pp files that exist ? 

Thanks again.


-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Wednesday, December 16, 2009 8:59 AM
To: Hasan Rezaul-CHR010
Cc: selinux@tycho.nsa.gov
Subject: Re: Policy writing philosophy...

On Tue, 2009-12-15 at 12:43 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I have Linux 2.6.27 on a non-popular Linux distro, and I have the 
> following SELinux package versions :
>   
> >  checkpolicy-2.0.19
> >  libselinux-2.0.85
> >  libsemanage-2.0.33
> >  libsepol-2.0.37
> >  policycoreutils-2.0.69
> >  sepolgen-1.0.17
> 
> I know SELinux's is governing framework is that by default everything 
> is DENIED, except all accesses that are explicitly allowed in the
policy...
> 
> Is there anyway whatsoever to reverse that philosophy ?  In other 
> words, is it possible to configure things and write policy in a way
such that:
> 
> Only explicit things are disallowed... So whenever no explicit policy 
> exists for an access request it is actually ALLOWED. This way, if I 
> write a new task or process, I don't have to write new policy for it 
> to allow all the things it needs. By default things will just be 
> allowed, unless some of those accesses have been explicitly disallowed

> in policy ?
> 
> My guess is that this CANT be done... But thought I would ask anyway ?

Not from a mechanism point of view, no.  But from a policy point of
view, you can achieve your end by initially declaring a domain as an
unconfined domain and then removing rules, or by declaring a domain as a
permissive domain and generating rules for it via audit2allow.

> Also can SELinux mappings be created for a Unix Group, as opposed to 
> mapping to individual Linux Users ?

Yes - just use %groupname in the seusers configuration.

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

[Stephen Smalley]

On Wed, 2009-12-16 at 10:30 -0500, Hasan Rezaul-CHR010 wrote:
> Thanks as always Stephen. 
> 
> >> Also can SELinux mappings be created for a Unix Group, as opposed to 
> >> mapping to individual Linux Users ?
> 
> > Yes - just use %groupname in the seusers configuration.
> 
> Would you kindly give me some more details / examples, or point me to a
> URL or document that I can learn more about how to achieve this ?
> Thanks again.

groupadd research
useradd -g research johndoe
semanage login -a -s user_u %research
ssh -l johndoe localhost
id

> Also, I have a Fedora 12 machine now. I was wondering, where can I get
> all the  ***.te  files for the corresponding ***.pp files that exist ? 

yumdownloader --source selinux-policy
rpm -ivh selinux-policy*.src.rpm

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

[Hasan Rezaul-CHR010]

Excellent!  Thanks Sir.
 

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Wednesday, December 16, 2009 9:48 AM
To: Hasan Rezaul-CHR010
Cc: Daniel J Walsh; selinux@tycho.nsa.gov
Subject: RE: Policy writing philosophy...

On Wed, 2009-12-16 at 10:30 -0500, Hasan Rezaul-CHR010 wrote:
> Thanks as always Stephen. 
> 
> >> Also can SELinux mappings be created for a Unix Group, as opposed 
> >> to mapping to individual Linux Users ?
> 
> > Yes - just use %groupname in the seusers configuration.
> 
> Would you kindly give me some more details / examples, or point me to 
> a URL or document that I can learn more about how to achieve this ?
> Thanks again.

groupadd research
useradd -g research johndoe
semanage login -a -s user_u %research
ssh -l johndoe localhost
id

> Also, I have a Fedora 12 machine now. I was wondering, where can I get

> all the  ***.te  files for the corresponding ***.pp files that exist ?

yumdownloader --source selinux-policy
rpm -ivh selinux-policy*.src.rpm

--
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: How to use sepolgen VS. policygentool

[Daniel J Walsh]

On 12/09/2009 09:18 PM, Hasan Rezaul-CHR010 wrote:
>  
> Hi All,
> 
> I used to have the following SELinux related package versions on my
> Linux (2.6.18) system:
>  
> checkpolicy      - 1.33.1
> libselinux       - 2.0.13
> libsemanage      - 2.0.1
> libsepol         - 2.0.3
> libsetrans       - 0.1.18
> policycoreutils  - 2.0.16
>  
> On that machine, I used to use  /usr/share/selinux/devel/policygentool
> to create new custom policy templates, and modified them as necessary,
> and used to run
> 
>  make -f /usr/share/selinux/devel/Makefile  to compile my  custom.te
> policies to create custom.pp.
> 
> I now have upgraded to Linux 2.6.27 on a non-popular Linux distro, and
> as part of this upgrade, we also migrated to much newer versions of the
> SELinux packages. They are:
>  
>  checkpolicy-2.0.19
>  libselinux-2.0.85
>  libsemanage-2.0.33
>  libsepol-2.0.37
>  policycoreutils-2.0.69
>  sepolgen-1.0.17
> 
> My questions are :
> 
> 1. On this new system, I don't see policygentool anymore ! Infact, I am
> missing the whole  /usr/share/selinux/devel/* directory.  Can I install
> the  selinux-policy-devel  package on this machine ? If so, where should
> I get it from ? Is policygentool still supported ?
> 
> 2. I do see this new package "sepolgen", which I am guessing is the
> newer replacement ? I do see that sepolgen is infact installed on my
> system:
> 
> 	root@unknown:/root> rpm -q sepolgen
> 	sepolgen-1.0.17-1_WR3.0.2as.ppc_e500v2
> 	root@unknown:/root>
> 	root@unknown:/root> which sepolgen
> 	which: no sepolgen in
> (/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/root/bin)
> 	root@unknown:/root>
> 	root@unknown:/root>
> 	root@unknown:/root> cd /usr/lib/sepolgen/
> 	root@unknown:/usr/lib/sepolgen> ls
> 	perm_map
> 	root@unknown:/usr/lib/sepolgen>
> 
> How do I use this sepolgen thing ?  I thought I could run an sepolgen
> executable as follows: "sepolgen -t <program>"
> But I don't see where the sepolgen executable is ??? Do I need to
> install any other packages to use sepolgen ?
> 
> 3. Finally, it seems that sepolgen will create a template policy based
> on a particular process, e.g. /usr/bin/ssh
> 
>    What if I wanted to write more generic policy for restricting selinux
> users. For example:
> 
>    neverallow user_t etc_t:file write;
>    neverallow user_t bin_t:file write;
>    neverallow user_t proc_t:file write;
>    neverallow staff_t bin_t:file write;
>    :
>    :
> 
>    what <program_name> should I supply in the sepolgen command, to
> create a custom policy template for this purpose ?
> 
> 
> Thanks in advance for all your help  :-)
>    

I think the problem here is upstream has not accepted all of the changes that have been put into Fedora.

sepolgen is part of the policycoreutils-gui package which has not gone upstream yet and should be pulled into another 
package.  You could grab the fedora src rpms and build them on your machine.

neverallow is not the opposite of allow.  neverallow says to the compiler, blow up if a new policy tries to add this rule.

user_t is not allowed by default to write to any of those types.

Everything is denied by default.

--
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: Where do I get a good Policy Base ?...

[Hasan Rezaul-CHR010]

Hi All,

I didn't get an answer to my question below  :-(
 

-------------------------------

Thanks for your answers   :-)

A quick follow up question...

What would be the most appropriate Fedora selinux-policy that I can
start off with as a base to build on top of, Given:

that I have Linux 2.6.27,  and I have the following latest SELinux
package versions :

 checkpolicy-2.0.19
 libselinux-2.0.85
 libsemanage-2.0.33
 libsepol-2.0.37
 policycoreutils-2.0.69
 sepolgen-1.0.17

Should I use Fedora 11 -   
download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages
/selinux-policy-3.6.6-5.fc11.noarch.rpm

Or should I use Fedora 10 -
download.fedora.redhat.com/pub/fedora/linux/updates/10/i386/selinux-poli
cy-3.5.13-45.fc10.noarch.rpm

Or should I use new RefPolicy from OpenSuSE -
ftp5.gwdg.de/pub/opensuse/repositories/security:/SELinux/openSUSE_Factor
y/noarch/selinux-policy-refpolicy-standard-2.20081210-1.8.noarch.rpm


Thanks in advance as usual for all your help.




-----Original Message-----
From: Dominick Grift [mailto:domg472@gmail.com]
Sent: Tuesday, October 27, 2009 3:50 AM
To: Hasan Rezaul-CHR010
Cc: selinux@tycho.nsa.gov
Subject: Re: Where do I get a good Policy Base ?...

On Mon, 2009-10-26 at 21:16 -0400, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I used to have the following SELinux related package versions on my 
> Linux (2.6.18) system:
> 
> Checkpolicy      - 1.33.1
> Libselinux       - 2.0.13
> Libsemanage      - 2.0.1
> Libsepol         - 2.0.3
> Libsetrans       - 0.1.18
> Policycoreutils  - 2.0.16
> 
> And I used a 'strict' Base policy from Fedora Core 6. Made the 
> modifications I needed on top of that, and I was very happy...
> 
> 
> We get our OS packaged/delivered from a third party company, and we're

> upgrading to Linux 2.6.27, and as part of this upgrade, we are also 
> migrating to much newer versions of the SELinux packages. They are:
> 
> checkpolicy-2.0.19
> libselinux-2.0.85
> libsemanage-2.0.33
> libsepol-2.0.37
> policycoreutils-2.0.69
> sepolgen-1.0.17
> 
> 
> My questions are:
> 
> 1. I believe the "strict" policy is no longer supported in the above 
> versions of SELinux packages? Is this true ?

the "strict" policy model is no longer supported. The strict and target
policy have merged to a policy model that is called "targeted". You can
configure the "targeted" policy to behave like old strict policy by
removing removing the unconfined modules and by mapping your Linux
logins to strict SELinux users.

> 
> 2. The entire set of policies that I have fine-tuned over the years 
> under my  /etc/selinux/strict/modules/active/modules/*.pp  directory 
> in my previous older system, can I make any use of that ?? In other 
> words, can that stuff be re-used at all ? Or do I need to develop 
> policy from scratch again ?

I am not sure about this but my opinion is that it should  in most cases
be possible to use older binary modules in newer policy. Reference
policy should be compatible in my view.

Please note though that is encouraged to keep the source policy for your
binary modules so that you can edit policy modules easily later.
> 
> 3. What will be a good base policy for me to start policy development 
> on ? Will it be refpolicy, or should I grab the base 'targeted' policy

> from fedora core 11 for example ?

This depends on your distro, but generally you should be better of with
a distro specific policy. Also keep in mind that Fedora has a active
community, frequent updates and many testers.

> 
> 4. Assuming 'strict' is no longer supported in the NEW package 
> versions above, and I use a base 'targeted' policy as my starting 
> point... Should I be able to simply remove the "unconfined.pp" policy 
> module from the base targeted policy, and that essentially turns my 
> system into "strict-like" mode ? Is that advisable ?

That is the idea, yes,

> 
> 5. If I do continue to use the 'targeted' base policy as is, how can I

> develop policy on top of that, to make sure I still block specific 
> things that I don't want to take place. For example, I DON'T want a 
> user_t to be able to write to files of type  etc_t  for example. How 
> do I go about accomplishing this  given the 'targeted' framework ? I 
> know how to do this in the old 'strict' framework, not sure how to go 
> about it with the targeted framework. Please shed some light or point 
> me to documents...

You can write your own custom policy modules on that of the policy that
is distributed. Current policy is usually modular. Basically write a
source policy module, build it and install it using the semanage or the
semodule command.

e.g. (Fedora/RedHat):

echo "policy_module(mytest, 0.0.1)" > mytest.te; make -f
/usr/share/selinux/devel/Makefile mytest.pp; sudo semodule -i mytest.pp
sudo semodule -l | grep mytest

> 
> Again, Any references or documentation links would be greatly 
> appreciated.

www.selinuxproject.org/page/User_Resources
> 
> Thanks in advance.
> 
> 
> --
> 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.




--
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: Where do I get a good Policy Base ?...

[Daniel J Walsh]

On 11/11/2009 02:37 PM, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I didn't get an answer to my question below  :-(
>  
> 
F12 policy.


> -------------------------------
> 
> Thanks for your answers   :-)
> 
> A quick follow up question...
> 
> What would be the most appropriate Fedora selinux-policy that I can
> start off with as a base to build on top of, Given:
> 
> that I have Linux 2.6.27,  and I have the following latest SELinux
> package versions :
> 
>  checkpolicy-2.0.19
>  libselinux-2.0.85
>  libsemanage-2.0.33
>  libsepol-2.0.37
>  policycoreutils-2.0.69
>  sepolgen-1.0.17
> 
> Should I use Fedora 11 -   
> download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages
> /selinux-policy-3.6.6-5.fc11.noarch.rpm
> 
> Or should I use Fedora 10 -
> download.fedora.redhat.com/pub/fedora/linux/updates/10/i386/selinux-poli
> cy-3.5.13-45.fc10.noarch.rpm
> 
> Or should I use new RefPolicy from OpenSuSE -
> ftp5.gwdg.de/pub/opensuse/repositories/security:/SELinux/openSUSE_Factor
> y/noarch/selinux-policy-refpolicy-standard-2.20081210-1.8.noarch.rpm
> 
> 
> Thanks in advance as usual for all your help.
> 
> 
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:domg472@gmail.com]
> Sent: Tuesday, October 27, 2009 3:50 AM
> To: Hasan Rezaul-CHR010
> Cc: selinux@tycho.nsa.gov
> Subject: Re: Where do I get a good Policy Base ?...
> 
> On Mon, 2009-10-26 at 21:16 -0400, Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I used to have the following SELinux related package versions on my 
>> Linux (2.6.18) system:
>>
>> Checkpolicy      - 1.33.1
>> Libselinux       - 2.0.13
>> Libsemanage      - 2.0.1
>> Libsepol         - 2.0.3
>> Libsetrans       - 0.1.18
>> Policycoreutils  - 2.0.16
>>
>> And I used a 'strict' Base policy from Fedora Core 6. Made the 
>> modifications I needed on top of that, and I was very happy...
>>
>>
>> We get our OS packaged/delivered from a third party company, and we're
> 
>> upgrading to Linux 2.6.27, and as part of this upgrade, we are also 
>> migrating to much newer versions of the SELinux packages. They are:
>>
>> checkpolicy-2.0.19
>> libselinux-2.0.85
>> libsemanage-2.0.33
>> libsepol-2.0.37
>> policycoreutils-2.0.69
>> sepolgen-1.0.17
>>
>>
>> My questions are:
>>
>> 1. I believe the "strict" policy is no longer supported in the above 
>> versions of SELinux packages? Is this true ?
> 
> the "strict" policy model is no longer supported. The strict and target
> policy have merged to a policy model that is called "targeted". You can
> configure the "targeted" policy to behave like old strict policy by
> removing removing the unconfined modules and by mapping your Linux
> logins to strict SELinux users.
> 
>>
>> 2. The entire set of policies that I have fine-tuned over the years 
>> under my  /etc/selinux/strict/modules/active/modules/*.pp  directory 
>> in my previous older system, can I make any use of that ?? In other 
>> words, can that stuff be re-used at all ? Or do I need to develop 
>> policy from scratch again ?
> 
> I am not sure about this but my opinion is that it should  in most cases
> be possible to use older binary modules in newer policy. Reference
> policy should be compatible in my view.
> 
> Please note though that is encouraged to keep the source policy for your
> binary modules so that you can edit policy modules easily later.
>>
>> 3. What will be a good base policy for me to start policy development 
>> on ? Will it be refpolicy, or should I grab the base 'targeted' policy
> 
>> from fedora core 11 for example ?
> 
> This depends on your distro, but generally you should be better of with
> a distro specific policy. Also keep in mind that Fedora has a active
> community, frequent updates and many testers.
> 
>>
>> 4. Assuming 'strict' is no longer supported in the NEW package 
>> versions above, and I use a base 'targeted' policy as my starting 
>> point... Should I be able to simply remove the "unconfined.pp" policy 
>> module from the base targeted policy, and that essentially turns my 
>> system into "strict-like" mode ? Is that advisable ?
> 
> That is the idea, yes,
> 
>>
>> 5. If I do continue to use the 'targeted' base policy as is, how can I
> 
>> develop policy on top of that, to make sure I still block specific 
>> things that I don't want to take place. For example, I DON'T want a 
>> user_t to be able to write to files of type  etc_t  for example. How 
>> do I go about accomplishing this  given the 'targeted' framework ? I 
>> know how to do this in the old 'strict' framework, not sure how to go 
>> about it with the targeted framework. Please shed some light or point 
>> me to documents...
> 
> You can write your own custom policy modules on that of the policy that
> is distributed. Current policy is usually modular. Basically write a
> source policy module, build it and install it using the semanage or the
> semodule command.
> 
> e.g. (Fedora/RedHat):
> 
> echo "policy_module(mytest, 0.0.1)" > mytest.te; make -f
> /usr/share/selinux/devel/Makefile mytest.pp; sudo semodule -i mytest.pp
> sudo semodule -l | grep mytest
> 
>>
>> Again, Any references or documentation links would be greatly 
>> appreciated.
> 
> www.selinuxproject.org/page/User_Resources
>>
>> Thanks in advance.
>>
>>
>> --
>> 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.
> 
> 


--
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: Where do I get a good Policy Base ?...

[Hasan Rezaul-CHR010]

Thanks Dan,

I cant seem to find a good place to download the selinux-policy rpm for
Fedora 12.  Can you point me to an URL link, or tell me how/where I can
obtain it ?

In general, when looking for what policy to use as a base, is it more
important to stay consistent about the Linux Kernel version, or is it
more important to make sure the versions of selinux-packages are
consistent ?  I am guessing it's the latter.

Thanks.


-----Original Message-----
From: Daniel J Walsh [mailto:dwalsh@redhat.com]
Sent: Wednesday, November 11, 2009 4:02 PM
To: Hasan Rezaul-CHR010
Cc: Stephen Smalley; selinux@tycho.nsa.gov
Subject: Re: Where do I get a good Policy Base ?...

On 11/11/2009 02:37 PM, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I didn't get an answer to my question below  :-(
>  
> 
F12 policy.


> -------------------------------
> 
> Thanks for your answers   :-)
> 
> A quick follow up question...
> 
> What would be the most appropriate Fedora selinux-policy that I can 
> start off with as a base to build on top of, Given:
> 
> that I have Linux 2.6.27,  and I have the following latest SELinux 
> package versions :
> 
>  checkpolicy-2.0.19
>  libselinux-2.0.85
>  libsemanage-2.0.33
>  libsepol-2.0.37
>  policycoreutils-2.0.69
>  sepolgen-1.0.17
> 
> Should I use Fedora 11 -   
> download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packag
> es /selinux-policy-3.6.6-5.fc11.noarch.rpm
> 
> Or should I use Fedora 10 -
> download.fedora.redhat.com/pub/fedora/linux/updates/10/i386/selinux-po
> li
> cy-3.5.13-45.fc10.noarch.rpm
> 
> Or should I use new RefPolicy from OpenSuSE - 
> ftp5.gwdg.de/pub/opensuse/repositories/security:/SELinux/openSUSE_Fact
> or
> y/noarch/selinux-policy-refpolicy-standard-2.20081210-1.8.noarch.rpm
> 
> 
> Thanks in advance as usual for all your help.
> 
> 
> 
> 
> -----Original Message-----
> From: Dominick Grift [mailto:domg472@gmail.com]
> Sent: Tuesday, October 27, 2009 3:50 AM
> To: Hasan Rezaul-CHR010
> Cc: selinux@tycho.nsa.gov
> Subject: Re: Where do I get a good Policy Base ?...
> 
> On Mon, 2009-10-26 at 21:16 -0400, Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I used to have the following SELinux related package versions on my 
>> Linux (2.6.18) system:
>>
>> Checkpolicy      - 1.33.1
>> Libselinux       - 2.0.13
>> Libsemanage      - 2.0.1
>> Libsepol         - 2.0.3
>> Libsetrans       - 0.1.18
>> Policycoreutils  - 2.0.16
>>
>> And I used a 'strict' Base policy from Fedora Core 6. Made the 
>> modifications I needed on top of that, and I was very happy...
>>
>>
>> We get our OS packaged/delivered from a third party company, and 
>> we're
> 
>> upgrading to Linux 2.6.27, and as part of this upgrade, we are also 
>> migrating to much newer versions of the SELinux packages. They are:
>>
>> checkpolicy-2.0.19
>> libselinux-2.0.85
>> libsemanage-2.0.33
>> libsepol-2.0.37
>> policycoreutils-2.0.69
>> sepolgen-1.0.17
>>
>>
>> My questions are:
>>
>> 1. I believe the "strict" policy is no longer supported in the above 
>> versions of SELinux packages? Is this true ?
> 
> the "strict" policy model is no longer supported. The strict and 
> target policy have merged to a policy model that is called "targeted".
> You can configure the "targeted" policy to behave like old strict 
> policy by removing removing the unconfined modules and by mapping your

> Linux logins to strict SELinux users.
> 
>>
>> 2. The entire set of policies that I have fine-tuned over the years 
>> under my  /etc/selinux/strict/modules/active/modules/*.pp  directory 
>> in my previous older system, can I make any use of that ?? In other 
>> words, can that stuff be re-used at all ? Or do I need to develop 
>> policy from scratch again ?
> 
> I am not sure about this but my opinion is that it should  in most 
> cases be possible to use older binary modules in newer policy.
> Reference policy should be compatible in my view.
> 
> Please note though that is encouraged to keep the source policy for 
> your binary modules so that you can edit policy modules easily later.
>>
>> 3. What will be a good base policy for me to start policy development

>> on ? Will it be refpolicy, or should I grab the base 'targeted'
>> policy
> 
>> from fedora core 11 for example ?
> 
> This depends on your distro, but generally you should be better of 
> with a distro specific policy. Also keep in mind that Fedora has a 
> active community, frequent updates and many testers.
> 
>>
>> 4. Assuming 'strict' is no longer supported in the NEW package 
>> versions above, and I use a base 'targeted' policy as my starting 
>> point... Should I be able to simply remove the "unconfined.pp" policy

>> module from the base targeted policy, and that essentially turns my 
>> system into "strict-like" mode ? Is that advisable ?
> 
> That is the idea, yes,
> 
>>
>> 5. If I do continue to use the 'targeted' base policy as is, how can 
>> I
> 
>> develop policy on top of that, to make sure I still block specific 
>> things that I don't want to take place. For example, I DON'T want a 
>> user_t to be able to write to files of type  etc_t  for example. How 
>> do I go about accomplishing this  given the 'targeted' framework ? I 
>> know how to do this in the old 'strict' framework, not sure how to go

>> about it with the targeted framework. Please shed some light or point

>> me to documents...
> 
> You can write your own custom policy modules on that of the policy 
> that is distributed. Current policy is usually modular. Basically 
> write a source policy module, build it and install it using the 
> semanage or the semodule command.
> 
> e.g. (Fedora/RedHat):
> 
> echo "policy_module(mytest, 0.0.1)" > mytest.te; make -f 
> /usr/share/selinux/devel/Makefile mytest.pp; sudo semodule -i 
> mytest.pp sudo semodule -l | grep mytest
> 
>>
>> Again, Any references or documentation links would be greatly 
>> appreciated.
> 
> www.selinuxproject.org/page/User_Resources
>>
>> Thanks in advance.
>>
>>
>> --
>> 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.
> 
> 



--
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: Where do I get a good Policy Base ?...

[Daniel J Walsh]

On 11/11/2009 06:25 PM, Hasan Rezaul-CHR010 wrote:
> Thanks Dan,
> 
> I cant seem to find a good place to download the selinux-policy rpm for
> Fedora 12.  Can you point me to an URL link, or tell me how/where I can
> obtain it ?
> 
> In general, when looking for what policy to use as a base, is it more
> important to stay consistent about the Linux Kernel version, or is it
> more important to make sure the versions of selinux-packages are
> consistent ?  I am guessing it's the latter.
> 
> Thanks.
> 
> 
> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
> Sent: Wednesday, November 11, 2009 4:02 PM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; selinux@tycho.nsa.gov
> Subject: Re: Where do I get a good Policy Base ?...
> 
> On 11/11/2009 02:37 PM, Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I didn't get an answer to my question below  :-(
>>  
>>
> F12 policy.
> 
> 
>> -------------------------------
>>
>> Thanks for your answers   :-)
>>
>> A quick follow up question...
>>
>> What would be the most appropriate Fedora selinux-policy that I can 
>> start off with as a base to build on top of, Given:
>>
>> that I have Linux 2.6.27,  and I have the following latest SELinux 
>> package versions :
>>
>>  checkpolicy-2.0.19
>>  libselinux-2.0.85
>>  libsemanage-2.0.33
>>  libsepol-2.0.37
>>  policycoreutils-2.0.69
>>  sepolgen-1.0.17
>>
>> Should I use Fedora 11 -   
>> download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packag
>> es /selinux-policy-3.6.6-5.fc11.noarch.rpm
>>
>> Or should I use Fedora 10 -
>> download.fedora.redhat.com/pub/fedora/linux/updates/10/i386/selinux-po
>> li
>> cy-3.5.13-45.fc10.noarch.rpm
>>
>> Or should I use new RefPolicy from OpenSuSE - 
>> ftp5.gwdg.de/pub/opensuse/repositories/security:/SELinux/openSUSE_Fact
>> or
>> y/noarch/selinux-policy-refpolicy-standard-2.20081210-1.8.noarch.rpm
>>
>>
>> Thanks in advance as usual for all your help.
>>
>>
>>
>>
>> -----Original Message-----
>> From: Dominick Grift [mailto:domg472@gmail.com]
>> Sent: Tuesday, October 27, 2009 3:50 AM
>> To: Hasan Rezaul-CHR010
>> Cc: selinux@tycho.nsa.gov
>> Subject: Re: Where do I get a good Policy Base ?...
>>
>> On Mon, 2009-10-26 at 21:16 -0400, Hasan Rezaul-CHR010 wrote:
>>> Hi All,
>>>
>>> I used to have the following SELinux related package versions on my 
>>> Linux (2.6.18) system:
>>>
>>> Checkpolicy      - 1.33.1
>>> Libselinux       - 2.0.13
>>> Libsemanage      - 2.0.1
>>> Libsepol         - 2.0.3
>>> Libsetrans       - 0.1.18
>>> Policycoreutils  - 2.0.16
>>>
>>> And I used a 'strict' Base policy from Fedora Core 6. Made the 
>>> modifications I needed on top of that, and I was very happy...
>>>
>>>
>>> We get our OS packaged/delivered from a third party company, and 
>>> we're
>>
>>> upgrading to Linux 2.6.27, and as part of this upgrade, we are also 
>>> migrating to much newer versions of the SELinux packages. They are:
>>>
>>> checkpolicy-2.0.19
>>> libselinux-2.0.85
>>> libsemanage-2.0.33
>>> libsepol-2.0.37
>>> policycoreutils-2.0.69
>>> sepolgen-1.0.17
>>>
>>>
>>> My questions are:
>>>
>>> 1. I believe the "strict" policy is no longer supported in the above 
>>> versions of SELinux packages? Is this true ?
>>
>> the "strict" policy model is no longer supported. The strict and 
>> target policy have merged to a policy model that is called "targeted".
>> You can configure the "targeted" policy to behave like old strict 
>> policy by removing removing the unconfined modules and by mapping your
> 
>> Linux logins to strict SELinux users.
>>
>>>
>>> 2. The entire set of policies that I have fine-tuned over the years 
>>> under my  /etc/selinux/strict/modules/active/modules/*.pp  directory 
>>> in my previous older system, can I make any use of that ?? In other 
>>> words, can that stuff be re-used at all ? Or do I need to develop 
>>> policy from scratch again ?
>>
>> I am not sure about this but my opinion is that it should  in most 
>> cases be possible to use older binary modules in newer policy.
>> Reference policy should be compatible in my view.
>>
>> Please note though that is encouraged to keep the source policy for 
>> your binary modules so that you can edit policy modules easily later.
>>>
>>> 3. What will be a good base policy for me to start policy development
> 
>>> on ? Will it be refpolicy, or should I grab the base 'targeted'
>>> policy
>>
>>> from fedora core 11 for example ?
>>
>> This depends on your distro, but generally you should be better of 
>> with a distro specific policy. Also keep in mind that Fedora has a 
>> active community, frequent updates and many testers.
>>
>>>
>>> 4. Assuming 'strict' is no longer supported in the NEW package 
>>> versions above, and I use a base 'targeted' policy as my starting 
>>> point... Should I be able to simply remove the "unconfined.pp" policy
> 
>>> module from the base targeted policy, and that essentially turns my 
>>> system into "strict-like" mode ? Is that advisable ?
>>
>> That is the idea, yes,
>>
>>>
>>> 5. If I do continue to use the 'targeted' base policy as is, how can 
>>> I
>>
>>> develop policy on top of that, to make sure I still block specific 
>>> things that I don't want to take place. For example, I DON'T want a 
>>> user_t to be able to write to files of type  etc_t  for example. How 
>>> do I go about accomplishing this  given the 'targeted' framework ? I 
>>> know how to do this in the old 'strict' framework, not sure how to go
> 
>>> about it with the targeted framework. Please shed some light or point
> 
>>> me to documents...
>>
>> You can write your own custom policy modules on that of the policy 
>> that is distributed. Current policy is usually modular. Basically 
>> write a source policy module, build it and install it using the 
>> semanage or the semodule command.
>>
>> e.g. (Fedora/RedHat):
>>
>> echo "policy_module(mytest, 0.0.1)" > mytest.te; make -f 
>> /usr/share/selinux/devel/Makefile mytest.pp; sudo semodule -i 
>> mytest.pp sudo semodule -l | grep mytest
>>
>>>
>>> Again, Any references or documentation links would be greatly 
>>> appreciated.
>>
>> www.selinuxproject.org/page/User_Resources
>>>
>>> Thanks in advance.
>>>
>>>
>>> --
>>> 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.
>>
>>
> 

Latest F12 packages are in koji, here is a link:

http://koji.fedoraproject.org/koji/buildinfo?buildID=140508

The Fedora Kernel can handle multiple different policies, so I am not sure I understand the question.

--
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: sshd error: Failed to get default security context

[Dominick Grift]

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

On Sat, Oct 17, 2009 at 07:39:50AM -0400, Daniel J Walsh wrote:
> On 10/16/2009 08:15 PM, Larry Ross wrote:
> > I have created a custom selinux user for the strict policy on RHEL5.3 who's
> > purpose is to connect via ssh and scp files off the machine.  When that user
> > tries to login via ssh, I see the following messages in /var/log/secure:
> > 
> > In enforcing:
> > Oct 16 07:49:40 localhost sshd[20461]: Accepted password for scpuser
> > from 192.168.1.1 port 64680 ssh2
> > Oct 16 07:49:40 localhost sshd[20461]: error: Failed to get default security
> > context for scpuser.
> > Oct 16 07:49:40 localhost sshd[20461]: fatal: SELinux failure. Aborting
> > connection.
> > 
> > In permissive:
> > Oct 16 07:55:59 localhost sshd[23302]: Accepted password for scpuser from
> > 192.168.1.1 port 56254 ssh2
> > Oct 16 07:55:59 localhost sshd[23302]: error: Failed to get default security
> > context for scpuser.
> > Oct 16 07:55:59 localhost sshd[23302]: error: SELinux failure. Continuing in
> > permissive mode.
> > 
> > Could someone explain what these messages mean?

I am not sure about el5 but in Fedora:

the files in /etc/selinux/<policy model>/contexts/targeted have specifications that tell the login programs what context to use for the specified seuser when he logs in.

I wrote an article about adding customized user domains for Fedora:

http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-four-customized.html

And some screencasts:

http://selinux-mac.blogspot.com/2009/06/selinux-screencasts.html

> > 
> > I believe that I have a default context defined in the "default context"
> > file that should work. I believe I have an executable context available for
> > this user (using rbash rather than bash).
> > 
> > How is sshd making this decision?  It looks like it is calling setexeccon,
> > but I'm not sure how that makes its decision.  Where should I look for clues
> > as to how to fix it?
> > 
> >    Thank you,
> >    Larry
> > 
> Did you add an entry to default_types?
> 
> --
> 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: sshd error: Failed to get default security context

[Larry Ross]

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

On Sun, Oct 18, 2009 at 3:33 AM, Dominick Grift <domg472@gmail.com> wrote:

> On Sat, Oct 17, 2009 at 07:39:50AM -0400, Daniel J Walsh wrote:
> > On 10/16/2009 08:15 PM, Larry Ross wrote:
> > > I have created a custom selinux user for the strict policy on RHEL5.3
> who's
> > > purpose is to connect via ssh and scp files off the machine.  When that
> user
> > > tries to login via ssh, I see the following messages in
> /var/log/secure:
> > >
> > > In enforcing:
> > > Oct 16 07:49:40 localhost sshd[20461]: Accepted password for scpuser
> > > from 192.168.1.1 port 64680 ssh2
> > > Oct 16 07:49:40 localhost sshd[20461]: error: Failed to get default
> security
> > > context for scpuser.
> > > Oct 16 07:49:40 localhost sshd[20461]: fatal: SELinux failure. Aborting
> > > connection.
> > >
> > > In permissive:
> > > Oct 16 07:55:59 localhost sshd[23302]: Accepted password for scpuser
> from
> > > 192.168.1.1 port 56254 ssh2
> > > Oct 16 07:55:59 localhost sshd[23302]: error: Failed to get default
> security
> > > context for scpuser.
> > > Oct 16 07:55:59 localhost sshd[23302]: error: SELinux failure.
> Continuing in
> > > permissive mode.
> > >
> > > Could someone explain what these messages mean?
>
> I am not sure about el5 but in Fedora:
>
> the files in /etc/selinux/<policy model>/contexts/targeted have
> specifications that tell the login programs what context to use for the
> specified seuser when he logs in.
>
> I wrote an article about adding customized user domains for Fedora:
>
>
> http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-four-customized.html
>
> And some screencasts:
>
> http://selinux-mac.blogspot.com/2009/06/selinux-screencasts.html


Dominick,
  Thanks for the links, I hadn't seen those before.  Those are great
examples of _how_ to do it.  I am looking for something that helps me to
understand _why_ things work the way they do.  In my case, I didn't need to
add my user to /etc/selinux/strict/contexts/users, nothing tells me to do
that or why it would work without it.  In fact, the strict policy only has
the root user defined there.

   Dan recommended updating "default_types", that wasn't needed, but I don't
know why he recommended that or how the system uses that file vs. the
default_contexts file, which I had modified to include my custom users.

   Can anyone point me to some current documentation that explains this (or
at least documentation that is not obviously out of date)?

   -- Larry



> > >
> > > I believe that I have a default context defined in the "default
> context"
> > > file that should work. I believe I have an executable context available
> for
> > > this user (using rbash rather than bash).
> > >
> > > How is sshd making this decision?  It looks like it is calling
> setexeccon,
> > > but I'm not sure how that makes its decision.  Where should I look for
> clues
> > > as to how to fix it?
> > >
> > >    Thank you,
> > >    Larry
> > >
> > Did you add an entry to default_types?
> >
> > --
> > This message was distributed to subscribers of the selinux mailing list.
> > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.govwith
> > the words "unsubscribe selinux" without quotes as the message.
>

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

Re: sshd error: Failed to get default security context

[Daniel J Walsh]

On 10/18/2009 02:58 PM, Larry Ross wrote:
> On Sun, Oct 18, 2009 at 3:33 AM, Dominick Grift <domg472@gmail.com> wrote:
> 
>> On Sat, Oct 17, 2009 at 07:39:50AM -0400, Daniel J Walsh wrote:
>>> On 10/16/2009 08:15 PM, Larry Ross wrote:
>>>> I have created a custom selinux user for the strict policy on RHEL5.3
>> who's
>>>> purpose is to connect via ssh and scp files off the machine.  When that
>> user
>>>> tries to login via ssh, I see the following messages in
>> /var/log/secure:
>>>>
>>>> In enforcing:
>>>> Oct 16 07:49:40 localhost sshd[20461]: Accepted password for scpuser
>>>> from 192.168.1.1 port 64680 ssh2
>>>> Oct 16 07:49:40 localhost sshd[20461]: error: Failed to get default
>> security
>>>> context for scpuser.
>>>> Oct 16 07:49:40 localhost sshd[20461]: fatal: SELinux failure. Aborting
>>>> connection.
>>>>
>>>> In permissive:
>>>> Oct 16 07:55:59 localhost sshd[23302]: Accepted password for scpuser
>> from
>>>> 192.168.1.1 port 56254 ssh2
>>>> Oct 16 07:55:59 localhost sshd[23302]: error: Failed to get default
>> security
>>>> context for scpuser.
>>>> Oct 16 07:55:59 localhost sshd[23302]: error: SELinux failure.
>> Continuing in
>>>> permissive mode.
>>>>
>>>> Could someone explain what these messages mean?
>>
>> I am not sure about el5 but in Fedora:
>>
>> the files in /etc/selinux/<policy model>/contexts/targeted have
>> specifications that tell the login programs what context to use for the
>> specified seuser when he logs in.
>>
>> I wrote an article about adding customized user domains for Fedora:
>>
>>
>> http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-four-customized.html
>>
>> And some screencasts:
>>
>> http://selinux-mac.blogspot.com/2009/06/selinux-screencasts.html
> 
> 
> Dominick,
>   Thanks for the links, I hadn't seen those before.  Those are great
> examples of _how_ to do it.  I am looking for something that helps me to
> understand _why_ things work the way they do.  In my case, I didn't need to
> add my user to /etc/selinux/strict/contexts/users, nothing tells me to do
> that or why it would work without it.  In fact, the strict policy only has
> the root user defined there.
> 
>    Dan recommended updating "default_types", that wasn't needed, but I don't
> know why he recommended that or how the system uses that file vs. the
> default_contexts file, which I had modified to include my custom users.
> 
>    Can anyone point me to some current documentation that explains this (or
> at least documentation that is not obviously out of date)?
> 
>    -- Larry
> 
> 
> 
>>>>
>>>> I believe that I have a default context defined in the "default
>> context"
>>>> file that should work. I believe I have an executable context available
>> for
>>>> this user (using rbash rather than bash).
>>>>
>>>> How is sshd making this decision?  It looks like it is calling
>> setexeccon,
>>>> but I'm not sure how that makes its decision.  Where should I look for
>> clues
>>>> as to how to fix it?
default_types tells the system which type to associate with a role.

User transitions are defined in several places.  

If you define a new role/type, you need to make sure your login program can transition to that role/type.  

# sesearch --allow -s sshd_t -p transition
Found 10 semantic av rules:
   allow sshd_t unpriv_userdomain : process { transition signal } ; 
   allow sshd_t nx_server_t : process transition ; 
   allow sshd_t oddjob_mkhomedir_t : process transition ; 
   allow sshd_t chkpwd_t : process transition ; 
   allow sshd_t passwd_t : process transition ; 
   allow sshd_t updpwd_t : process transition ; 
   allow sshd_t mount_t : process transition ; 
   allow sshd_t rssh_t : process transition ; 
   allow unconfined_login_domain unconfined_t : process transition ; 
   allow polydomain setfiles_t : process transition ; 

Probably defining your type as a unpriv_userdomain will allow this.

You also need to make sure system_r can reach your role

# sesearch --role_allow | grep system_r
   allow system_r sysadm_r;
   allow sysadm_r system_r;
   allow system_r guest_r;
   allow logadm_r system_r;
   allow system_r logadm_r;
   allow system_r nx_server_r;
   allow system_r staff_r;
   allow unconfined_r system_r;
   allow system_r unconfined_r;
   allow system_r user_r;
   allow webadm_r system_r;
   allow system_r webadm_r;
   allow system_r xguest_r;


Basically this means system_r:sshd_t can transition to myrole_r:myrole_t

Now you need to setup the user database.

You need to make sure your SELinux User includes that role.

# semanage user -a -R myrole_r myuser_u

Then you need to make sure your Linux User maps to your new user
# semanage login -a -s myuser_u dwalsh

Now you need to make sure the default transitions happen correctly.

for example.

Then you need to edit your 
/etc/selinux/targeted/contexts/default_contexts
or preferably
/etc/selinux/targeted/contexts/users/myrole_u

file.  The login program reads /etc/selinux/targeted/contexts/users/myrole_u first 

Hopefully all of this will be setup correctly and your domain should be reached.
>>>>
>>>>    Thank you,
>>>>    Larry
>>>>
>>> Did you add an entry to default_types?
>>>
>>> --
>>> This message was distributed to subscribers of the selinux mailing list.
>>> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.govwith
>>> the words "unsubscribe selinux" without quotes as the message.
>>
> 


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