5:17 a.m.
On 05/16/2010 10:51 AM, Dominick Grift wrote:
On Sat, May 15, 2010 at 09:33:01PM -0700, David Highley wrote:
> "Dominick Grift wrote:"
>>
>> 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;
>
> Looking at what was needed to get this working with the other install
> method I now have the following for the sshdfilter.te file:
You can use the following instead. That way you do not have to require external, types
classes.
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)
allow iptables_t self:fifo_file rw_fifo_file_perms;
Whoops actually the above does not belong here. You already added that
to your "myiptables" module below.
allow sshdfilter_t sshdfilter_etc_t:file read_file_perms;
dev_read_urand(sshdfilter_t)
corecmd_search_bin(sshdfilter_t)
miscfiles_read_localization(sshdfilter_t)
optional_policy(`
iptables_domtrans(sshdfilter_t)
")
# I would like to see the raw AVC denial for this.
# allow sshdfilter_t var_run_t:file getattr;
>
> I also tried this modification for iptables:
> policy_module(myiptables, 1.0.0)
> optional_policy(`
> gen_require(`
> type iptables_t;
> ')
> corecmd_read_bin_symlinks(iptables_t)
> allow iptables_t self:fifo_file rw_fifo_file_perms;
> ')
The above looks fine.
> I'm not getting any avc audit log etries but the script is getting hung
> at this line of code:
> open(TABCHECK,"$iptables -L -n | grep \"^$chain *tcp\"|") ||
> die("couldn't check $iptables");
>
> I run this command logged in as root and it work fine. Block even in
> permissive mode. I should have also let you know I'm running Fedora 12.
> So it would appear that the script is not able to run iptables.
You mean to say that it does not work with the system in permissive mode (setenforce 0)?
If it does not work in permissive mode, then you can rule out any SElinux related issue.
If it works in permissive modebut not in enforcing mode then it is a SElinux issue (be
aware i mean full permissive mode not permissive domains)
>>
>> # 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.
>>
>>> =20
>>> 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 t=
>> o
>>> get this into the repo.