Generating policy for embedded platforms.

Generating policy for embedded platforms.

[Sam Gandhi]

Hello,

Hopefully this is appropriate mailing list for this type of email, if
not please do let what is the appropriate forum for questions below.

I am trying to enable SELinux on a embedded platform running linux 2.6.35.

One of the idea we have is to run seLinux is permissive mode and
gather the AVC messages as our programs start and convert those
messages to 'allow' policy and deny everything else, much like what is
done in IP packet forwarding, allow only traffic you know you want to
process and deny everything else.

Now the question are: is how does one generate deny-all policy for SELinux?

I have come across mdp program in kernel source code and
install_policy.sh script is that the right way to get started on
building the most minimum policy set for embedded system, where large
desktop policy may not be appropriate?

Below is the script I am trying to use to setup the dummy policy (as
described in Documentation/SELinux.txt), and booting kernel with
enforcing=0 selinux=1 kernel parameters.

problem is I don't see any of the avc messages as my applications
start and open files/sockets etc. What am I doing wrong?


cd /tmp/
VERS=`checkpolicy -V  | awk '{print $1}'`
/bin/mdp policy.conf file_contexts
checkpolicy -o policy.$VERS policy.conf
mkdir -p /etc/selinux/dummy/policy
mkdir -p /etc/selinux/dummy/contexts/files
cp file_contexts /etc/selinux/dummy/contexts/files
cp policy.$VERS /etc/selinux/dummy/policy
echo "user system_u roles system_r;" >> /etc/selinux/dummy/policy/users
echo "user root roles { staff_r sysadm_r };" >>
/etc/selinux/dummy/policy/users
cat > /etc/selinux/config << EOF
SELINUX=permissive
SELINUXTYPE=dummy
EOF

Sam

--
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: Generating policy for embedded platforms.

[Stephen Smalley]

On Thu, 2011-04-14 at 09:07 -0700, Sam Gandhi wrote:
> Hello,
> 
> Hopefully this is appropriate mailing list for this type of email, if
> not please do let what is the appropriate forum for questions below.
> 
> I am trying to enable SELinux on a embedded platform running linux 2.6.35.
> 
> One of the idea we have is to run seLinux is permissive mode and
> gather the AVC messages as our programs start and convert those
> messages to 'allow' policy and deny everything else, much like what is
> done in IP packet forwarding, allow only traffic you know you want to
> process and deny everything else.
> 
> Now the question are: is how does one generate deny-all policy for SELinux?
> 
> I have come across mdp program in kernel source code and
> install_policy.sh script is that the right way to get started on
> building the most minimum policy set for embedded system, where large
> desktop policy may not be appropriate?
> 
> Below is the script I am trying to use to setup the dummy policy (as
> described in Documentation/SELinux.txt), and booting kernel with
> enforcing=0 selinux=1 kernel parameters.
> 
> problem is I don't see any of the avc messages as my applications
> start and open files/sockets etc. What am I doing wrong?

First, are you loading the policy into the kernel at boot?  That is the
responsibility of early userspace, typically handled from /sbin/init or
the initramfs script.  Look for messages from SELinux in dmesg output
beyond the initial ones, along the lines of:
SELinux: 2048 avtab hash slots, 215487 rules.
SELinux: 2048 avtab hash slots, 215487 rules.
SELinux:  9 users, 14 roles, 3521 types, 184 bools, 1 sens, 1024 cats
SELinux:  81 classes, 215487 rules
SELinux:  Completing initialization.
SELinux:  Setting up existing superblocks.
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
...

Second, if you use the policy generated by mdp, you'll have a policy
with exactly one type that is allowed to do everything.  So you'll see
no denials at all until you start adding further types to the policy.
New types are not automatically generated by audit2allow - you have to
create them.  A type is a security equivalence class, so you don't need
one for every individual program or file, only where you need to
distinguish permissions.

-- 
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: Generating policy for embedded platforms.

[Sam Gandhi]

On Thu, Apr 14, 2011 at 10:04 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Thu, 2011-04-14 at 09:07 -0700, Sam Gandhi wrote:
>> Hello,
>>
>> Hopefully this is appropriate mailing list for this type of email, if
>> not please do let what is the appropriate forum for questions below.
>>
>> I am trying to enable SELinux on a embedded platform running linux 2.6.35.
>>
>> One of the idea we have is to run seLinux is permissive mode and
>> gather the AVC messages as our programs start and convert those
>> messages to 'allow' policy and deny everything else, much like what is
>> done in IP packet forwarding, allow only traffic you know you want to
>> process and deny everything else.
>>
>> Now the question are: is how does one generate deny-all policy for SELinux?
>>
>> I have come across mdp program in kernel source code and
>> install_policy.sh script is that the right way to get started on
>> building the most minimum policy set for embedded system, where large
>> desktop policy may not be appropriate?
>>
>> Below is the script I am trying to use to setup the dummy policy (as
>> described in Documentation/SELinux.txt), and booting kernel with
>> enforcing=0 selinux=1 kernel parameters.
>>
>> problem is I don't see any of the avc messages as my applications
>> start and open files/sockets etc. What am I doing wrong?
>
> First, are you loading the policy into the kernel at boot?  That is the
> responsibility of early userspace, typically handled from /sbin/init or
> the initramfs script.  Look for messages from SELinux in dmesg output
> beyond the initial ones, along the lines of:
> SELinux: 2048 avtab hash slots, 215487 rules.
> SELinux: 2048 avtab hash slots, 215487 rules.
> SELinux:  9 users, 14 roles, 3521 types, 184 bools, 1 sens, 1024 cats
> SELinux:  81 classes, 215487 rules
> SELinux:  Completing initialization.
> SELinux:  Setting up existing superblocks.
> SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
> ...
I do see following messages related to SeLinux during boot time.
SELinux: 4 avtab hash slots, 3 rules.
SELinux: 4 avtab hash slots, 3 rules.
SELinux:  1 users, 2 roles, 1 types, 0 bools
SELinux:  75 classes, 3 rules
SELinux:  Completing initialization.
SELinux:  Setting up existing superblocks.

>
> Second, if you use the policy generated by mdp, you'll have a policy
> with exactly one type that is allowed to do everything.  So you'll see
> no denials at all until you start adding further types to the policy.

I removed all the allow statements in the policy.conf generated by mdp
and left just one allow statement

allow base_t base_t:user73 *;

Now see the AVC messages as my daemons start, will convert them to
policy statement using audi2allow. Is this the right approach in
generating minimal policy for embedded platforms?

-Sam


--
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: Generating policy for embedded platforms.

[Stephen Smalley]

On Thu, 2011-04-14 at 11:06 -0700, Sam Gandhi wrote:
> I removed all the allow statements in the policy.conf generated by mdp
> and left just one allow statement
> 
> allow base_t base_t:user73 *;
> 
> Now see the AVC messages as my daemons start, will convert them to
> policy statement using audi2allow. Is this the right approach in
> generating minimal policy for embedded platforms?

That will just generate a policy with all processes running in base_t
and all files labeled with base_t; audit2allow doesn't generate new
types for you.  You need to give some thought to that your security
goals are, what subjects and objects you want to distinguish, define
types and type transitions for those subjects and objects, and label the
subject executables and objects accordingly.  Only then can you begin to
exercise the system and "learn" policy using audit2allow.  You can of
course do this incrementally, e.g. start by splitting out some small set
of subject types (aka "domains") and some coarse-grained division of
your filesystem into a small number of file types, and refine it over
time.

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