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.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
