Need new secret sauce

[Dominick Grift]

On 05/08/2010 04:20 AM, David Highley wrote:

I took a quick look at the README file enclosed with the archive, and i
think the second route may be the better solution since you might be
able to isolate sshdfilter from ssh for a large part.

This is in my view important because sshd is a trusted service, meaning
it is allowed much access becuase it needs it and we rely on sshd for
security.

Below you will find a starting point for policy for sshdfilter in the
second scenario. This policy is incomplete and it may also have errors.
You might be able to use it as a starting point and to perfect the
policy. That would require testing, extending policy (using audit2allow
and common sense) rebuilding, reinstalling policy , retesting etc. until
it is perfect.

To do that you must ensure that you have configured the service properly
and that you do the development ofthe policy and testing in a secure
environment.

1. Establishing sshdfilter object locations:

So from the README file i understand theres 3 files:

- The initscript (/etc/rc.d/init.d/sshdfilter
- The config file(s) (/etc/sshdfilterrc.*)
- The sshdfilter application executable file (/usr/sbin/sshdfilter)

2. Declare types for sshdfilter objects, the sshdfilter subject, then
makes the types usable type for their purpose and define file context
specifications for the sshdfilter file objects. Additionally make the
sshdfilter subject type permissive (will not work in el5) to make
testing more easy and secure.

3. Source policy module for sshdfilter.

Create a work directory. This is where we will store the source policy
module for our sshdfilter application. Keep the source policy module, as
you may need to extend, modify, rebuild it later.

A Selinux source policy module has 3 files. A type enforcement file
("modulename".te), A interface file ("modulename.if"), and a file
context specification file ("modulename".fc).

The type enforcement file has declarations and policy that are local to
the module. The interface file has policy where the target of the
interaction is a type declared in the type enforcement file of the
module. e.g. shared policy. If external domains want to interact with
sshdfilter in anyway, then the sshdfilter.if file should facilitate any
access required for other domains to interact with it. The file context
specification file has file object context specifications for file
object types that are declared in the type enforcement file.

4. sshdfilter.te

touch a file called sshdfilter.te in your working directory. The file
will be split in two parts: first the personal declarations and second
the personal policy.

Add the following to the sshdfilter.te file:

policy_module(sshdfilter, 1.0.0)

type sshdfilter_t;
type sshdfilter_exec_t;
init_daemon_domain(sshdfilter_t, sshdfilter_exec_t)

type sshdfilter_initrc_exec_t;
init_script_file(sshdfilter_initrc_exec_t)

type sshdfilter_etc_t;
files_config_file(sshdfilter_etc_t)

# permissive domains will not work in el5.
permissve sshdfilter_t;

# policy below (todo)

So above we declared types for the 3 files and te process. We started by
declaring a new policy module called sshdfilter and gave it a version
number of 1.0.0. Once the module is installed you can use semodule -l to
list these policy module details.

sshdfilter_t is the type that is declared for the sshdfilter process.
sshdfilter_exec_t is the type declared for the sshdfilter application
executable file (/usr/sbin/sshdfilter)

Both type are made a init daemon domain by calling the
init_daemon_domain() interface with the two types as parameters. This is
just a macro that gets expanded with m4 to actual policy that the kernel
can understand. The macros are used to make policy maintainable for
humans. Basically its a way to group policy.

The type sshdfilter_initrc_exec_t type is the type for the sshdfilter
init script (/etc/rc.d/init.d/sshdfilter)
This type is made a valid init script file type by calling the
init_script_file interface and supplying the type used for the init
script as a parameter.

The next type declared is sshdfilter_etc_t, This is the type for the
sshdfilter configuration files (/etc/sshdfilterrc.*) The type is made
usuable for configuration files by calling files_config_file(), with the
type that we have declared for sshdfilters file objects in /etc as its
parameter.

Finally we made the subject type sshdfilter_t a "permissive domain".
This may not work on older selinux implementations.

Permissive domains is a way to run a single domain in permissive mode as
opposed to running the full system in permissive mode when one runs the
setenforce 0 command. This allows you to test a single domain.

We did not add any policy yet to out type enforcement file. This is
because i do not know what access the application needs. You can find
out by testing, editing policy, testing etc. The audit2allow command and
ausearch command can help parse AVC denials which can be used to extend
your sshdfilter_t domain.

5. sshdfilter.fc

We declared the types for sshdfilter in our type enforcement source
policy file. Now we must assign the file object types to actual objects
on the file system. e.g. create file object context specifications.

Add the following to the sshdfilter.fc file:

/etc/rc\.d/init\.d/sshdfilter --
gen_context(system_u:object_r:sshdfilter_initrc_exec_t, s0)
/etc/sshdfilterrc.* -- gen_context(system_u:object_r:sshdfilter_etc_t, s0)
/usr/sbin/sshdfilter -- gen_context(system_u:object_r:sshdfilter_exec_t, s0)

That will tell the system what file object to label with the types we
declared for our domain.

6. sshdfilter.if

We will skip this section for simplicity. We may need it later, if it
turns out some other domain wants to interact with out sshdfilter_t
domain or any file object types it owns.

7. Building and installing.

By now we should have a solid foundation for our new domain. By solid i
mean that the domain type is declared (sshfilter_t) and all (known)
objects own by the sshdfilter_t domain have types declared and file
object contexts specified.

The init_daemon_domain() interface call provides all policy that is
needed for init to transition into the sshdfilter_t domain.

The permissive domain sshdfilter_t will allow sshdfilter_t all access
but will log "would be denied" access vectors.

If you are using an older selinux implementation, you may want to
comment that line out and do the policy testing with selinux in
permissive mode instead.

cd into your working dir and run the following to build a binary
representation of the sshdfilter source policy module:

make -f /usr/share/selinux/devel/Makefile sshdfilter.pp

( on el5 this requires that you have the selinux-policy-devel package
installed )

If all goes well this should create the binary policy module which we
can load into the policy store with the following command:

sudo semodule -i sshdfilter.pp

Use the semodule command to list, install , reinstall , remove modules.

Now all you have to do is restore the contexts of the objects defined in
the sshdfilter.fc file to reflect the type we declared in our type
enforcement file.

Then just run and test the app, either in permissive mode or if possible
using the permissive domain declaration described above.

Collect any AVC denials for dmesg , /var/log/messages
/var/log/audit/audit.log and use those AVC denials to make policy
decisions and extend your type enforcement file.

Rebuild a new binary representation afterward, reinstall it into the
policy store and test it all over again. Repeat this untill all AVC
denials are gone and untill your application works like it should.

Any questions? Please let me know.

Disclaimer: The may be errors above. Try at your own risk.

> 
> I'm attaching the down load. It has two methods of installation so the
> files vary depending on approach. I wonder if there would be some way to
> get this into the repo.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20100510/bcd235a4/attachment.bin