Security Context Type Changes

Security Context Type Changes

[Tomas, Gregg A (IS)]

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

Hi

 

We are currently integrating our SELinux Policy on a RHEL5 machine.
However, we are having difficulty in restricting our application within
a specific directory because "something" changes our security context
type of our users to init_t instead of unconfined_t. Root gets changed
to (i.e. <user>:<role>:init_t). We are running with init level 4. We
must have tried everything in the book to determine what changes the
security context type of our users. Would anyone have any tips?

 

We did change inittab to run init level 5, touch /.autorelabel,
rebooted, checked id -Z  and it is unconfined_t. However, ultimately we
would like to run with init 4.

 

Thanks in advance.


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

Re: Security Context Type Changes

[Stephen Smalley]

On Wed, 2010-01-06 at 16:34 -0600, Tomas, Gregg A (IS) wrote:
> Hi
> 
>  
> 
> We are currently integrating our SELinux Policy on a RHEL5 machine.
> However, we are having difficulty in restricting our application
> within a specific directory because “something” changes our security
> context type of our users to init_t instead of unconfined_t. Root gets
> changed to (i.e. <user>:<role>:init_t). We are running with init level
> 4. We must have tried everything in the book to determine what changes
> the security context type of our users. Would anyone have any tips?
> 
>  
> 
> We did change inittab to run init level 5, touch /.autorelabel,
> rebooted, checked id –Z  and it is unconfined_t. However, ultimately
> we would like to run with init 4.

What is your /etc/inittab configuration for run level 4?

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

Help with an SELinux AVC event...

[Hasan Rezaul-CHR010]

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

Hi All,

I have a C application task called "sswd" on my Linux system, that opens up the /var/log/audit/audit.log file every 5 seconds, and checks to see if there are any new AVC denies.

I have had this same task doing the same thing for the last few years on a Linux system running selinux. And I have never seen these events in audit.log before complaining about the sswd task... I used to use older selinux packages, and ran the Fedora Core 7 'strict' policy together with some custom policies.

Recently we upgraded our SELinux packages to the very latest (similar to Fedora 12), and we are using Refpolicy as a base policy.

In the /var/log/audit/audit.log file, I see the following event pop up every 5 seconds, and I am guessing its because "sswd" tries to open up the audit.log file every 5 seconds for reading. 

1. Can you help me understand what this event is really saying?
2. I have already taken the audit.log file, and used audit2allow to generate any allow rules necessary, but it didnt help to get rid of this particular event.
3. Can I add any specific policy allow lines or transition rules in my custom policy files to get rid of this repeated event ?

Thanks in advance.

The event that pops up every 5 seconds in audit.log is:

type=SYSCALL msg=audit(1262874266.422:260): arch=14 syscall=5 success=yes exit=24 a0=1002b9e4 a1=0 a2=1b6 a3=1b6 items=1 ppid=2463 pid=2794 auid=4294967295 uid=0 gid=601 euid=0 suid=0 fsuid=0 egid=601 sgid=601 fsgid=601 tty=(none) ses=4294967295 comm="sswd" exe="/usr/app/bin/sswd" subj=system_u:system_r:init_t:s0-s15:c0.c255 key="LOG_audit"
type=CWD msg=audit(1262874266.422:260):  cwd="/data"
type=PATH msg=audit(1262874266.422:260): item=0 name="/var/log/audit/audit.log" inode=2061 dev=fd:07 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:auditd_log_t:s15:c0.c255

root@hapWibbSc2:/var/log/audit# ps -eZ | grep sswd
system_u:system_r:init_t:s0-s15:c0.c255 2781 ? 00:00:00 sswd

root@hapWibbSc2:/var/log/audit# cd /usr/app/bin
root@hapWibbSc2:/usr/app/bin# ls -l sswd
-rwxrwxr-x 1 root root 217204 Jan  1 07:49 sswd

root@hapWibbSc2:/usr/app/bin# cd /var/log/audit/
root@hapWibbSc2:/var/log/audit# 
root@hapWibbSc2:/var/log/audit# ls -lZ
-rw-------  root root system_u:object_r:auditd_log_t:s15:c0.c255 audit.log
 

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

Re: Help with an SELinux AVC event...

[Stephen Smalley]

On Thu, 2010-01-07 at 15:37 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I have a C application task called "sswd" on my Linux system, that
> opens up the /var/log/audit/audit.log file every 5 seconds, and checks
> to see if there are any new AVC denies.
> 
> I have had this same task doing the same thing for the last few years
> on a Linux system running selinux. And I have never seen these events
> in audit.log before complaining about the sswd task... I used to use
> older selinux packages, and ran the Fedora Core 7 'strict' policy
> together with some custom policies.
> 
> Recently we upgraded our SELinux packages to the very latest (similar
> to Fedora 12), and we are using Refpolicy as a base policy.
> 
> In the /var/log/audit/audit.log file, I see the following event pop up
> every 5 seconds, and I am guessing its because "sswd" tries to open up
> the audit.log file every 5 seconds for reading.
> 
> 1. Can you help me understand what this event is really saying?
> 2. I have already taken the audit.log file, and used audit2allow to
> generate any allow rules necessary, but it didnt help to get rid of
> this particular event.
> 3. Can I add any specific policy allow lines or transition rules in my
> custom policy files to get rid of this repeated event ?
> 
> Thanks in advance.
> 
> The event that pops up every 5 seconds in audit.log is:
> 
> type=SYSCALL msg=audit(1262874266.422:260): arch=14 syscall=5
> success=yes exit=24 a0=1002b9e4 a1=0 a2=1b6 a3=1b6 items=1 ppid=2463
> pid=2794 auid=4294967295 uid=0 gid=601 euid=0 suid=0 fsuid=0 egid=601
> sgid=601 fsgid=601 tty=(none) ses=4294967295 comm="sswd"
> exe="/usr/app/bin/sswd" subj=system_u:system_r:init_t:s0-s15:c0.c255
> key="LOG_audit"
> type=CWD msg=audit(1262874266.422:260):  cwd="/data"
> type=PATH msg=audit(1262874266.422:260): item=0
> name="/var/log/audit/audit.log" inode=2061 dev=fd:07 mode=0100600
> ouid=0 ogid=0 rdev=00:00
> obj=system_u:object_r:auditd_log_t:s15:c0.c255

That's your audit configuration (/etc/audit/audit.rules), not SELinux.
You have an audit rule that says to log all access to the audit log
file, presumably copied from the sample audit rules for the CAPP or LSPP
configurations.  Looks like this in audit.rules:
-w /var/log/audit/ -k LOG_audit

I think you'd be better off using audispd to dispatch audit events to
your program rather than directly reading audit.log yourself.
> 
> root@hapWibbSc2:/var/log/audit# ps -eZ | grep sswd
> system_u:system_r:init_t:s0-s15:c0.c255 2781 ? 00:00:00 sswd
> 
> root@hapWibbSc2:/var/log/audit# cd /usr/app/bin
> root@hapWibbSc2:/usr/app/bin# ls -l sswd
> -rwxrwxr-x 1 root root 217204 Jan  1 07:49 sswd
> 
> root@hapWibbSc2:/usr/app/bin# cd /var/log/audit/
> root@hapWibbSc2:/var/log/audit#
> root@hapWibbSc2:/var/log/audit# ls -lZ
> -rw-------  root root system_u:object_r:auditd_log_t:s15:c0.c255
> audit.log
> 
> 
> 
-- 
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: Help with an SELinux AVC event...

[Daniel J Walsh]

On 01/07/2010 03:43 PM, Stephen Smalley wrote:
> On Thu, 2010-01-07 at 15:37 -0500, Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I have a C application task called "sswd" on my Linux system, that
>> opens up the /var/log/audit/audit.log file every 5 seconds, and checks
>> to see if there are any new AVC denies.
>>
>> I have had this same task doing the same thing for the last few years
>> on a Linux system running selinux. And I have never seen these events
>> in audit.log before complaining about the sswd task... I used to use
>> older selinux packages, and ran the Fedora Core 7 'strict' policy
>> together with some custom policies.
>>
>> Recently we upgraded our SELinux packages to the very latest (similar
>> to Fedora 12), and we are using Refpolicy as a base policy.
>>
>> In the /var/log/audit/audit.log file, I see the following event pop up
>> every 5 seconds, and I am guessing its because "sswd" tries to open up
>> the audit.log file every 5 seconds for reading.
>>
>> 1. Can you help me understand what this event is really saying?
>> 2. I have already taken the audit.log file, and used audit2allow to
>> generate any allow rules necessary, but it didnt help to get rid of
>> this particular event.
>> 3. Can I add any specific policy allow lines or transition rules in my
>> custom policy files to get rid of this repeated event ?
>>
>> Thanks in advance.
>>
>> The event that pops up every 5 seconds in audit.log is:
>>
>> type=SYSCALL msg=audit(1262874266.422:260): arch=14 syscall=5
>> success=yes exit=24 a0=1002b9e4 a1=0 a2=1b6 a3=1b6 items=1 ppid=2463
>> pid=2794 auid=4294967295 uid=0 gid=601 euid=0 suid=0 fsuid=0 egid=601
>> sgid=601 fsgid=601 tty=(none) ses=4294967295 comm="sswd"
>> exe="/usr/app/bin/sswd" subj=system_u:system_r:init_t:s0-s15:c0.c255
>> key="LOG_audit"
>> type=CWD msg=audit(1262874266.422:260):  cwd="/data"
>> type=PATH msg=audit(1262874266.422:260): item=0
>> name="/var/log/audit/audit.log" inode=2061 dev=fd:07 mode=0100600
>> ouid=0 ogid=0 rdev=00:00
>> obj=system_u:object_r:auditd_log_t:s15:c0.c255
> 
> That's your audit configuration (/etc/audit/audit.rules), not SELinux.
> You have an audit rule that says to log all access to the audit log
> file, presumably copied from the sample audit rules for the CAPP or LSPP
> configurations.  Looks like this in audit.rules:
> -w /var/log/audit/ -k LOG_audit
> 
> I think you'd be better off using audispd to dispatch audit events to
> your program rather than directly reading audit.log yourself.
>>
>> root@hapWibbSc2:/var/log/audit# ps -eZ | grep sswd
>> system_u:system_r:init_t:s0-s15:c0.c255 2781 ? 00:00:00 sswd
>>
>> root@hapWibbSc2:/var/log/audit# cd /usr/app/bin
>> root@hapWibbSc2:/usr/app/bin# ls -l sswd
>> -rwxrwxr-x 1 root root 217204 Jan  1 07:49 sswd
>>
>> root@hapWibbSc2:/usr/app/bin# cd /var/log/audit/
>> root@hapWibbSc2:/var/log/audit#
>> root@hapWibbSc2:/var/log/audit# ls -lZ
>> -rw-------  root root system_u:object_r:auditd_log_t:s15:c0.c255
>> audit.log
>>
>>
>>
You probably want to steal the code in sedisp in the setroubleshoot package, since this is exactly what it does.

--
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: Help with an SELinux AVC event...

[Hasan Rezaul-CHR010]

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

Awesome ! What would I do without this maillist.  Thanks soo much for your wonderful help as always  :-)


-----Original Message-----
From: Daniel J Walsh [mailto:dwalsh@redhat.com]
Sent: Thu 1/7/2010 3:52 PM
To: Stephen Smalley
Cc: Hasan Rezaul-CHR010; Tomas, Gregg A (IS); selinux@tycho.nsa.gov
Subject: Re: Help with an SELinux AVC event...
 
On 01/07/2010 03:43 PM, Stephen Smalley wrote:
> On Thu, 2010-01-07 at 15:37 -0500, Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I have a C application task called "sswd" on my Linux system, that
>> opens up the /var/log/audit/audit.log file every 5 seconds, and checks
>> to see if there are any new AVC denies.
>>
>> I have had this same task doing the same thing for the last few years
>> on a Linux system running selinux. And I have never seen these events
>> in audit.log before complaining about the sswd task... I used to use
>> older selinux packages, and ran the Fedora Core 7 'strict' policy
>> together with some custom policies.
>>
>> Recently we upgraded our SELinux packages to the very latest (similar
>> to Fedora 12), and we are using Refpolicy as a base policy.
>>
>> In the /var/log/audit/audit.log file, I see the following event pop up
>> every 5 seconds, and I am guessing its because "sswd" tries to open up
>> the audit.log file every 5 seconds for reading.
>>
>> 1. Can you help me understand what this event is really saying?
>> 2. I have already taken the audit.log file, and used audit2allow to
>> generate any allow rules necessary, but it didnt help to get rid of
>> this particular event.
>> 3. Can I add any specific policy allow lines or transition rules in my
>> custom policy files to get rid of this repeated event ?
>>
>> Thanks in advance.
>>
>> The event that pops up every 5 seconds in audit.log is:
>>
>> type=SYSCALL msg=audit(1262874266.422:260): arch=14 syscall=5
>> success=yes exit=24 a0=1002b9e4 a1=0 a2=1b6 a3=1b6 items=1 ppid=2463
>> pid=2794 auid=4294967295 uid=0 gid=601 euid=0 suid=0 fsuid=0 egid=601
>> sgid=601 fsgid=601 tty=(none) ses=4294967295 comm="sswd"
>> exe="/usr/app/bin/sswd" subj=system_u:system_r:init_t:s0-s15:c0.c255
>> key="LOG_audit"
>> type=CWD msg=audit(1262874266.422:260):  cwd="/data"
>> type=PATH msg=audit(1262874266.422:260): item=0
>> name="/var/log/audit/audit.log" inode=2061 dev=fd:07 mode=0100600
>> ouid=0 ogid=0 rdev=00:00
>> obj=system_u:object_r:auditd_log_t:s15:c0.c255
> 
> That's your audit configuration (/etc/audit/audit.rules), not SELinux.
> You have an audit rule that says to log all access to the audit log
> file, presumably copied from the sample audit rules for the CAPP or LSPP
> configurations.  Looks like this in audit.rules:
> -w /var/log/audit/ -k LOG_audit
> 
> I think you'd be better off using audispd to dispatch audit events to
> your program rather than directly reading audit.log yourself.
>>
>> root@hapWibbSc2:/var/log/audit# ps -eZ | grep sswd
>> system_u:system_r:init_t:s0-s15:c0.c255 2781 ? 00:00:00 sswd
>>
>> root@hapWibbSc2:/var/log/audit# cd /usr/app/bin
>> root@hapWibbSc2:/usr/app/bin# ls -l sswd
>> -rwxrwxr-x 1 root root 217204 Jan  1 07:49 sswd
>>
>> root@hapWibbSc2:/usr/app/bin# cd /var/log/audit/
>> root@hapWibbSc2:/var/log/audit#
>> root@hapWibbSc2:/var/log/audit# ls -lZ
>> -rw-------  root root system_u:object_r:auditd_log_t:s15:c0.c255
>> audit.log
>>
>>
>>
You probably want to steal the code in sedisp in the setroubleshoot package, since this is exactly what it does.


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

RE: Security Context Type Changes

[Tomas, Gregg A (IS)]

Thank you Stephen for replying.

The following is our inittab configuration


id:4:initdefault:

~:S:wait:/sbin/sulogin

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Things to run in every runlevel.
#ud::once:/sbin/update

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"


# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6

# Run project specific stuff in runlevel 4
# The following script executes the Xserver
plo1:4:respawn:/<some directory>/run_xstart.bash

We changed the last line to the following:
plo1:4:respawn:runcon -t unconfined_t /testdir/run_xstart.bash

and it changed the security context type from init_t to unconfined_t. It worked but we still don't know why it would changed. RHEL4 did not change the type. None of our scripts have changed.

Thanks for your help.

Gregg


-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Thursday, January 07, 2010 6:15 AM
To: Tomas, Gregg A (IS)
Cc: selinux@tycho.nsa.gov
Subject: Re: Security Context Type Changes

On Wed, 2010-01-06 at 16:34 -0600, Tomas, Gregg A (IS) wrote:
> Hi
> 
>  
> 
> We are currently integrating our SELinux Policy on a RHEL5 machine.
> However, we are having difficulty in restricting our application
> within a specific directory because “something” changes our security
> context type of our users to init_t instead of unconfined_t. Root gets
> changed to (i.e. <user>:<role>:init_t). We are running with init level
> 4. We must have tried everything in the book to determine what changes
> the security context type of our users. Would anyone have any tips?
> 
>  
> 
> We did change inittab to run init level 5, touch /.autorelabel,
> rebooted, checked id –Z  and it is unconfined_t. However, ultimately
> we would like to run with init 4.

What is your /etc/inittab configuration for run level 4?

-- 
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: Security Context Type Changes

[Stephen Smalley]

On Sun, 2010-01-10 at 17:43 -0600, Tomas, Gregg A (IS) wrote:
> Thank you Stephen for replying.
> 
> The following is our inittab configuration
> 
> 
> id:4:initdefault:
> 
> ~:S:wait:/sbin/sulogin
> 
> # System initialization.
> si::sysinit:/etc/rc.d/rc.sysinit
> 
> l0:0:wait:/etc/rc.d/rc 0
> l1:1:wait:/etc/rc.d/rc 1
> l2:2:wait:/etc/rc.d/rc 2
> l3:3:wait:/etc/rc.d/rc 3
> l4:4:wait:/etc/rc.d/rc 4
> l5:5:wait:/etc/rc.d/rc 5
> l6:6:wait:/etc/rc.d/rc 6
> 
> # Things to run in every runlevel.
> #ud::once:/sbin/update
> 
> # Trap CTRL-ALT-DELETE
> ca::ctrlaltdel:/sbin/shutdown -t3 -r now
> 
> # When our UPS tells us power has failed, assume we have a few minutes
> # of power left.  Schedule a shutdown for 2 minutes from now.
> # This does, of course, assume you have powerd installed and your
> # UPS connected and working correctly.
> pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
> 
> # If power was restored before the shutdown kicked in, cancel it.
> pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
> 
> 
> # Run gettys in standard runlevels
> 1:2345:respawn:/sbin/mingetty tty1
> 2:2345:respawn:/sbin/mingetty tty2
> #3:2345:respawn:/sbin/mingetty tty3
> #4:2345:respawn:/sbin/mingetty tty4
> #5:2345:respawn:/sbin/mingetty tty5
> #6:2345:respawn:/sbin/mingetty tty6
> 
> # Run project specific stuff in runlevel 4
> # The following script executes the Xserver
> plo1:4:respawn:/<some directory>/run_xstart.bash
> 
> We changed the last line to the following:
> plo1:4:respawn:runcon -t unconfined_t /testdir/run_xstart.bash
> 
> and it changed the security context type from init_t to unconfined_t. It worked but we still don't know why it would changed. RHEL4 did not change the type. None of our scripts have changed.
> 
> Thanks for your help.

What does run_xstart.bash do?  Normally /sbin/init does not directly
start the X server, and thus the policy doesn't define any transition on
it, so it is normal that it would stay in init_t.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

SELinux questions...

[Hasan Rezaul-CHR010]

Hi All,

I have a few questions that I had asked in the past, so I apologize in
advance for the repetition. I had a hard-drive crash recently and lost
all my old emails  :-(

1. What was the SEMANAGE syntax to add selinux user mappings for a GROUP
as opposed to creating selinux mappings to a specific Linux user ?

2. What was the link to the "SELinux User Guide" document that a few
people have been putting together ?

3. Other than the document above, is there any other useful documents
out there that describe the design details and framework for the latest
Refpolicy?

Thanks as always for 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: SELinux questions...

[Stephen Smalley]

On Tue, 2010-01-12 at 14:37 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I have a few questions that I had asked in the past, so I apologize in
> advance for the repetition. I had a hard-drive crash recently and lost
> all my old emails  :-(

Searchable selinux archive:
http://marc.info/?l=selinux

> 1. What was the SEMANAGE syntax to add selinux user mappings for a GROUP
> as opposed to creating selinux mappings to a specific Linux user ?

http://marc.info/?l=selinux&m=126097853132648&w=2

> 2. What was the link to the "SELinux User Guide" document that a few
> people have been putting together ?

http://selinuxproject.org/page/Main_Page

> 3. Other than the document above, is there any other useful documents
> out there that describe the design details and framework for the latest
> Refpolicy?

http://oss.tresys.com/projects/refpolicy

-- 
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: SELinux questions...

[Daniel J Walsh]

On 01/12/2010 02:37 PM, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I have a few questions that I had asked in the past, so I apologize in
> advance for the repetition. I had a hard-drive crash recently and lost
> all my old emails  :-(
> 
> 1. What was the SEMANAGE syntax to add selinux user mappings for a GROUP
> as opposed to creating selinux mappings to a specific Linux user ?
> 
%name same as sudoers

man semanage
...
       semanage login -{a|d|m} [-sr] login_name | %groupname


> 2. What was the link to the "SELinux User Guide" document that a few
> people have been putting together ?
> 
http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/

> 3. Other than the document above, is there any other useful documents
> out there that describe the design details and framework for the latest
> Refpolicy?
> 
Well this document exists also.

http://docs.fedoraproject.org/selinux-managing-confined-services-guide/en-US/F11/html/

Not quite what you want.

http://oss.tresys.com/projects/refpolicy

> Thanks as always for 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: SELinux questions...

[Dominick Grift]

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

On 01/12/2010 08:37 PM, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I have a few questions that I had asked in the past, so I apologize in
> advance for the repetition. I had a hard-drive crash recently and lost
> all my old emails  :-(
> 
> 1. What was the SEMANAGE syntax to add selinux user mappings for a GROUP
> as opposed to creating selinux mappings to a specific Linux user ?

from man semanage:
$ semanage login -a -s user_u %clerks


> 2. What was the link to the "SELinux User Guide" document that a few
> people have been putting together ?

http://docs.fedoraproject.org/selinux-user-guide/f12/en-US/

> 3. Other than the document above, is there any other useful documents
> out there that describe the design details and framework for the latest
> Refpolicy?

http://www.selinuxbyexample.com
http://selinuxproject.org
http://oss.tresys.com
http://docs.fedoraproject.org/selinux-managing-confined-services-guide/en-US/F11/html/
http://www.nsa.gov/research/selinux

> Thanks as always for 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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

RE: Security Context Type Changes

[Tomas, Gregg A (IS)]

Stephen,

I apologize for my lack promptness, I have been in and out of the
office. We are in the middle of transitioning from RHEL4 to RHEL5 so
some of the links maybe off. Anyhow, here is our run_xstart.bash script:
========================================================================
========================
PATH=/usr/X11R6/bin:$PATH; export PATH
MODE=standalone
BACKEND=localhost

#
#       Do any computer-specific processing necessary
#
if [[ ! -f /tmp/.quickstart ]]; then
    #
    #   Put up the screen background
    #
    ROOTW=$(/usr/bin/X11/xrdb -symbols | \
          awk 'BEGIN {FS="="} $1 ~ /-DWIDTH/ {print $2}')
    DEPTH=$(/usr/bin/X11/xrdb -symbols | awk 'BEGIN {FS="="}
$1~/^-DPLANES$/ {print $2}')
    echo "ROOT WIDTH = $ROOTW"
    if [ $ROOTW -ge 1024 ] ; then
        ####BGFILE=hgttg-5.gif
        BGFILE=app-1024.gif
    elif [ $ROOTW -ge 800 ]; then
        BGFILE=app-800.gif
    else
        BGFILE=app-640.gif
    fi

    if [ "$ROOTW" -eq 640 -a "$DEPTH" -eq 8 ]
    then
        echo "not displaying background picture"
    else
        /usr/bin/X11/xloadimage -onroot -center -border black \
           -quiet -private /h/ProjectX/images/$BGFILE &
    fi
fi

#
#       Start the window manager
#
export HOME=/h/ProjectX
export SHELL=/bin/bash
sleep 1

# Get ip address of primary display #
DISPLAY1=$DISPLAY;export DISPLAY1

# Start window manager for primary display #
exec /usr/bin/fvwm -display $DISPLAY1 \
     -cmd "Read /h/ProjectX/config_values/system.fvwmrc"

========================================================================
===============


Thanks again.

Gregg

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Monday, January 11, 2010 11:24 AM
To: Tomas, Gregg A (IS)
Cc: selinux@tycho.nsa.gov
Subject: RE: Security Context Type Changes

On Sun, 2010-01-10 at 17:43 -0600, Tomas, Gregg A (IS) wrote:
> Thank you Stephen for replying.
> 
> The following is our inittab configuration
> 
> 
> id:4:initdefault:
> 
> ~:S:wait:/sbin/sulogin
> 
> # System initialization.
> si::sysinit:/etc/rc.d/rc.sysinit
> 
> l0:0:wait:/etc/rc.d/rc 0
> l1:1:wait:/etc/rc.d/rc 1
> l2:2:wait:/etc/rc.d/rc 2
> l3:3:wait:/etc/rc.d/rc 3
> l4:4:wait:/etc/rc.d/rc 4
> l5:5:wait:/etc/rc.d/rc 5
> l6:6:wait:/etc/rc.d/rc 6
> 
> # Things to run in every runlevel.
> #ud::once:/sbin/update
> 
> # Trap CTRL-ALT-DELETE
> ca::ctrlaltdel:/sbin/shutdown -t3 -r now
> 
> # When our UPS tells us power has failed, assume we have a few minutes
> # of power left.  Schedule a shutdown for 2 minutes from now.
> # This does, of course, assume you have powerd installed and your
> # UPS connected and working correctly.
> pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting
Down"
> 
> # If power was restored before the shutdown kicked in, cancel it.
> pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown
Cancelled"
> 
> 
> # Run gettys in standard runlevels
> 1:2345:respawn:/sbin/mingetty tty1
> 2:2345:respawn:/sbin/mingetty tty2
> #3:2345:respawn:/sbin/mingetty tty3
> #4:2345:respawn:/sbin/mingetty tty4
> #5:2345:respawn:/sbin/mingetty tty5
> #6:2345:respawn:/sbin/mingetty tty6
> 
> # Run project specific stuff in runlevel 4
> # The following script executes the Xserver
> plo1:4:respawn:/<some directory>/run_xstart.bash
> 
> We changed the last line to the following:
> plo1:4:respawn:runcon -t unconfined_t /testdir/run_xstart.bash
> 
> and it changed the security context type from init_t to unconfined_t.
It worked but we still don't know why it would changed. RHEL4 did not
change the type. None of our scripts have changed.
> 
> Thanks for your help.

What does run_xstart.bash do?  Normally /sbin/init does not directly
start the X server, and thus the policy doesn't define any transition on
it, so it is normal that it would stay in init_t.

-- 
Stephen Smalley
National Security Agency



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Security Context Type Changes

[Stephen Smalley]

On Tue, 2010-01-19 at 15:15 -0600, Tomas, Gregg A (IS) wrote:
> Stephen,
> 
> I apologize for my lack promptness, I have been in and out of the
> office. We are in the middle of transitioning from RHEL4 to RHEL5 so
> some of the links maybe off. Anyhow, here is our run_xstart.bash script:
> ========================================================================
> ========================
<snip>
> # Start window manager for primary display #
> exec /usr/bin/fvwm -display $DISPLAY1 \
>      -cmd "Read /h/ProjectX/config_values/system.fvwmrc"
> 
> ========================================================================
> ===============

So why would you expect that to transition out of init_t?
Unless you've specifically labeled /usr/bin/fvwm with an entrypoint type
and defined a type transition on it, you'll just continue in init_t.

You aren't executing anything that would set up a user context, e.g. gdm
or friends.
 
-- 
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: Security Context Type Changes

[Tomas, Gregg A (IS)]

Stephen,

That is correct, we are not executing anything that would set up a user
context. Nothing in our code or our policy would change the context. In
RHEL4, root and any other users have a security context type of
unconfined_t so we would it expect it to be the same on RHEL5 but they
are init_t. Perhaps, something changed with RHEL5 release that I need to
research.

Thanks,


Gregg

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Tuesday, January 19, 2010 1:27 PM
To: Tomas, Gregg A (IS)
Cc: selinux@tycho.nsa.gov
Subject: RE: Security Context Type Changes

On Tue, 2010-01-19 at 15:15 -0600, Tomas, Gregg A (IS) wrote:
> Stephen,
> 
> I apologize for my lack promptness, I have been in and out of the
> office. We are in the middle of transitioning from RHEL4 to RHEL5 so
> some of the links maybe off. Anyhow, here is our run_xstart.bash
script:
>
========================================================================
> ========================
<snip>
> # Start window manager for primary display #
> exec /usr/bin/fvwm -display $DISPLAY1 \
>      -cmd "Read /h/ProjectX/config_values/system.fvwmrc"
> 
>
========================================================================
> ===============

So why would you expect that to transition out of init_t?
Unless you've specifically labeled /usr/bin/fvwm with an entrypoint type
and defined a type transition on it, you'll just continue in init_t.

You aren't executing anything that would set up a user context, e.g. gdm
or friends.
 
-- 
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: Security Context Type Changes

[Stephen Smalley]

On Wed, 2010-01-20 at 10:50 -0600, Tomas, Gregg A (IS) wrote:
> Stephen,
> 
> That is correct, we are not executing anything that would set up a user
> context. Nothing in our code or our policy would change the context. In
> RHEL4, root and any other users have a security context type of
> unconfined_t so we would it expect it to be the same on RHEL5 but they
> are init_t. Perhaps, something changed with RHEL5 release that I need to
> research.

Normally it is programs such as login (non-graphical console login), gdm
(graphical console login), or sshd (remote login) that set up the
security context for a user session.  If you were executing your script
directly from /etc/inittab under RHEL4, you should have had the same end
result - it would stay in init_t until/unless it executed a program for
which a domain transition was defined or a program that explicitly set a
context.  Possibly you were labeling your script or fvwm with a type and
defining a domain transition on 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.