Non-Computing Abstractions & An Issue Thereof

Non-Computing Abstractions & An Issue Thereof

[Joshua Kramer]

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

Hello,

I am trying to wrap my head around using SELinux to secure data objects 
in userspace.  My learning style suggests that for a topic like this, I 
abstract the theory away from how it's actually implemented in 
software.  To those ends, I have created the type enforcement file 
attached to this email, that loosely models the behavior of teams of 
sled dogs using SELinux.

When I try to install the policy using these commands:

checkmodule -M -m -o seSledDogs.mod seSledDogs.te
semodule_package -o seSledDogs.pp -m seSledDogs.mod
semodule -i ./seSledDogs.pp

...I get this error from semodule:

libsepol.print_missing_requirements: seSledDogs's global requirements 
were not met: role dog_owner_r (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or 
directory).
semodule:  Failed!

If I comment out the roles, I get a similar message about the types:

libsepol.print_missing_requirements: seSledDogs's global requirements 
were not met: type/attribute medicine_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or 
directory).
semodule:  Failed!

Where do I need to be defining these roles and types?  I was under the 
impression that the te files were self-contained.

Thanks!
-Joshua Kramer



[-- Attachment #2: seSledDogs.te --]
[-- Type: text/plain, Size: 3458 bytes --]


module seSledDogs 1.0;

require {

    # ----- SPECIFICATION.  This specifies what things are.

    # Classes.  The class describes a basic type of object
    # with which one can interact, and the interactions one
    # can have.  For example, with a _sled_ you can pull,
    # load, unload.  On the Linux side, an example of a
    # class is _file_: you can read, write, and perform
    # other operations on files.

    class sled { connect disconnect pull load unload embark disembark };
    class food { eat share }; 

    # Type definitions:  These describe the types of objects
    # with which the dogs will be interacting.  In this case
    # we have sleds that carry food, medicine, and people.

    # In the Linux world, Types describe the objects such
    # as files - for example, the files under /etc are
    # labelled with the type etc_t.

    type food_t;
    type medicine_t;
    type passenger_t;

    # Domains:  For this example, Domains are the functions
    # that are available to dogs.  Once a dog is assigned
    # a task (a "process"), the dog becomes part of a domain.
    # In dog terms the closest analogy is a Team - for example,
    # the instance of Dog named Nakita is on Team "Deliver
    # Medicine to Anchorage", hence domain meds_delivery_t.

    # In the Linux world, Domains are functions available to
    # particular programs or daemons.  For example, postgresql_t
    # is the Domain available for running instances of the
    # PostgreSQL daemon.

    type human_function_t;
    type dog_food_delivery_t;
    type dog_meds_delivery_t;
    type dog_people_delivery_t;
    type eating_t;

    # RBAC:  In this case, a 'role' describes a human
    # being that can interact with a dog.

    # In the Linux world, this is analogus to the roles such
    # as user_r, staff_r, and sysadm_r.

    role passenger_r;
    role sled_driver_r;
    role dog_owner_r;

} # end of 'require' statement

# ----- END SPECIFICATION

# ----- PERMISSIONS: What we allow and deny -----

# Permissions Rules:  Here we get to the meat of things.
# What should we allow, and what should we deny?  Note that
# anything that is not allowed here is denied; for example,
# dogs on the meds_delivery_t team cannot pull sleds
# of type passenger_t, because that is not explicitly
# permitted.

# Humans work in the 'human_function_t' domain.

# Humans can load and unload sleds of type food_t:
allow human_function_t food_t:sled { load unload };

# Humans can load and unload sleds of type medicine_t:
allow human_function_t medicine_t:sled { load unload };

# Humans can load, unload, embark, and disembark from
# sleds of type passenger_t:
allow human_function_t passenger_t:sled { load unload embark disembark };

# Humans can eat and share food of type food_t:
allow human_function_t food_t:food { eat share };

# Dogs, that are on the food delivery team (dog_food_delivery_t)
# can pull sleds of type food_t:
allow dog_food_delivery_t food_t:sled pull;

# Dogs on the meds_delivery_t team can pull sleds of type
# medicine_t:
allow dog_meds_delivery_t medicine_t:sled pull;

# Dogs on the people_delivery_t team can pull sleds of type
# passenger_t:
allow dog_people_delivery_t passenger_t:sled pull;


# All Dogs can eat and share food of type food_t:
allow dog_food_delivery_t food_t:food { eat share };
allow dog_meds_delivery_t food_t:food { eat share };
allow dog_people_delivery_t food_t:food { eat share };

# ----- END PERMISSIONS

Re: Non-Computing Abstractions & An Issue Thereof

[Stephen Smalley]

On Sat, 2010-05-29 at 17:40 -0400, Joshua Kramer wrote:
> Hello,
> 
> I am trying to wrap my head around using SELinux to secure data objects 
> in userspace.  My learning style suggests that for a topic like this, I 
> abstract the theory away from how it's actually implemented in 
> software.  To those ends, I have created the type enforcement file 
> attached to this email, that loosely models the behavior of teams of 
> sled dogs using SELinux.
> 
> When I try to install the policy using these commands:
> 
> checkmodule -M -m -o seSledDogs.mod seSledDogs.te
> semodule_package -o seSledDogs.pp -m seSledDogs.mod
> semodule -i ./seSledDogs.pp
> 
> ...I get this error from semodule:
> 
> libsepol.print_missing_requirements: seSledDogs's global requirements 
> were not met: role dog_owner_r (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file or 
> directory).
> semodule:  Failed!
> 
> If I comment out the roles, I get a similar message about the types:
> 
> libsepol.print_missing_requirements: seSledDogs's global requirements 
> were not met: type/attribute medicine_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file or 
> directory).
> semodule:  Failed!
> 
> Where do I need to be defining these roles and types?  I was under the 
> impression that the te files were self-contained.

A require block specifies the dependencies of the module; it does not
define them.  So if you put a symbol in a require block that is not
defined by any module, the module linking will fail as above.

Also note that you cannot define new classes/permissions in any non-base
module presently; they have to be defined in the base module.  That
should change in the future but is a limitation of the current
toolchain.

-- 
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: Non-Computing Abstractions & An Issue Thereof

[Chad Sellers]

On 5/29/10 5:40 PM, "Joshua Kramer" <josh@globalherald.net> wrote:

> Hello,
> 
> I am trying to wrap my head around using SELinux to secure data objects
> in userspace.  My learning style suggests that for a topic like this, I
> abstract the theory away from how it's actually implemented in
> software.  To those ends, I have created the type enforcement file
> attached to this email, that loosely models the behavior of teams of
> sled dogs using SELinux.
> 
> When I try to install the policy using these commands:
> 
> checkmodule -M -m -o seSledDogs.mod seSledDogs.te
> semodule_package -o seSledDogs.pp -m seSledDogs.mod
> semodule -i ./seSledDogs.pp
> 
> ...I get this error from semodule:
> 
> libsepol.print_missing_requirements: seSledDogs's global requirements
> were not met: role dog_owner_r (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file or
> directory).
> semodule:  Failed!
> 
The error says that things you specified as requirements for your policy
module to work (within the require block) don't exist in the rest of the
policy on the system. The require block in a policy module is for specifying
things that are required to exist outside of this module.

Assuming you do not expect food_t, medicine_t, etc. to exist outside your
module, but rather expect your module to declare those things, you should
move them out of the require block.

> If I comment out the roles, I get a similar message about the types:
> 
> libsepol.print_missing_requirements: seSledDogs's global requirements
> were not met: type/attribute medicine_t (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file or
> directory).
> semodule:  Failed!
> 
> Where do I need to be defining these roles and types?  I was under the
> impression that the te files were self-contained.
> 
Policy files (.te) are not self-contained, they are modules that are linked
together with the rest of the modules to create the system policy (that's
what semodule does). So, a .te file can declare things (say a type) and use
it internally, or it can require things from elsewhere in order to grant
access between something local and something elsewhere.

Hope that helps,
Chad Sellers
 


--
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: Non-Computing Abstractions & An Issue Thereof

[Richard Haines]

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

I've modified your module to compile and added a few notes - HOWEVER it does get a bit complicated as you need to add your new object classes and permissions to the base policy (as explained in the various emails). 

I've attached a tarball with sample files and a README. If you want, try these but of course you will not be able to enforce any policy but at least
it compiles.

Both examples in the README use information from the SELinux Notebook at:
http://www.freetechbooks.com/the-selinux-notebook-the-foundations-t785.html

One is based on a simple policy and the other on the Fedora 12 targeted reference policy.

Richard

--- On Sat, 29/5/10, Joshua Kramer <josh@globalherald.net> wrote:

> From: Joshua Kramer <josh@globalherald.net>
> Subject: Non-Computing Abstractions & An Issue Thereof
> To: "SE Linux" <selinux@tycho.nsa.gov>
> Date: Saturday, 29 May, 2010, 22:40
> Hello,
> 
> I am trying to wrap my head around using SELinux to secure
> data objects in userspace.  My learning style suggests
> that for a topic like this, I abstract the theory away from
> how it's actually implemented in software.  To those
> ends, I have created the type enforcement file attached to
> this email, that loosely models the behavior of teams of
> sled dogs using SELinux.
> 
> When I try to install the policy using these commands:
> 
> checkmodule -M -m -o seSledDogs.mod seSledDogs.te
> semodule_package -o seSledDogs.pp -m seSledDogs.mod
> semodule -i ./seSledDogs.pp
> 
> ...I get this error from semodule:
> 
> libsepol.print_missing_requirements: seSledDogs's global
> requirements were not met: role dog_owner_r (No such file or
> directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No
> such file or directory).
> semodule:  Failed!
> 
> If I comment out the roles, I get a similar message about
> the types:
> 
> libsepol.print_missing_requirements: seSledDogs's global
> requirements were not met: type/attribute medicine_t (No
> such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No
> such file or directory).
> semodule:  Failed!
> 
> Where do I need to be defining these roles and types? 
> I was under the impression that the te files were
> self-contained.
> 
> Thanks!
> -Joshua Kramer
> 
> 
>

[-- Attachment #2: SledDogs.tar.gz --]
[-- Type: application/x-gzip, Size: 6714 bytes --]

Re: Non-Computing Abstractions & An Issue Thereof

[Joshua Kramer]

On 06/03/2010 12:28 PM, Richard Haines wrote:
> I've modified your module to compile and added a few notes - HOWEVER it does get a bit complicated as you need to add your new object classes and permissions to the base policy (as explained in the various emails).
>    
THANKS Richard!  I am in the process of putting together a step-by-step 
'from the ground up' on how to do this on RedHat EL6.  I have consulted 
your notebooks and it's the best companion to the RH documentation for 
recent developments in SELinux.  And yeah, I do intend to write a 
userspace object manager next...

Thanks,
-JK

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