On Sun, May 16, 2010 at 01:06:53PM -0700, David Highley wrote:
"Dominick Grift wrote:"
>
> 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, meani=
> ng
> >>> 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 error=
> s.
> >>> You might be able to use it as a starting point and to perfect the
> >>> policy. That would require testing, extending policy (using audit2all=
> ow
> >>> and common sense) rebuilding, reinstalling policy , retesting etc. un=
> til
> >>> it is perfect.
> >>>
> >>> To do that you must ensure that you have configured the service prope=
> rly
> >>> 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 polic=
> y
> >>> 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 a=
> ny
> >>> access required for other domains to interact with it. The file conte=
> xt
> >>> 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 secon=
> d
> >>> 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:
> >=20
> > You can use the following instead. That way you do not have to require =
> external, types classes.=09
> > =20
> > policy_module(sshdfilter, 1.0.0)
> > =20
> > type sshdfilter_t;
> > type sshdfilter_exec_t;
> > init_daemon_domain(sshdfilter_t, sshdfilter_exec_t)
> > =20
> > type sshdfilter_initrc_exec_t;
> > init_script_file(sshdfilter_initrc_exec_t)
> > =20
> > type sshdfilter_etc_t;
> > files_config_file(sshdfilter_etc_t)
> >=20
> > allow iptables_t self:fifo_file rw_fifo_file_perms;
OK, some progress. The script is now starting and functioning as a
daemon. Just changed the sshdfilter.te file to the following and that
got it running:
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)
dev_read_urand(sshdfilter_t)
corecmd_search_bin(sshdfilter_t)
miscfiles_read_localization(sshdfilter_t)
optional_policy(`
iptables_domtrans(sshdfilter_t)
')
Had to rework the init.d script and changed the non standard pid file
name. The testing host is not behaving quite right and so far I have
not found out what is causing it. When I do a port scan I should see a
line like this in the secure file:
May 16 12:37:10 spruce sshd[30708]: Did not receive identification
string from 10.2.2.7
In testing so far it appears that the script can read the fifo even
though we did not do anything beyond creating the fifo. I would thought
we needed to label it.
What do you mean? iptables_t read and writes a fifo_file, not sshdfilter_t:
allow iptables_t self:fifo_file rw_fifo_file_perms;
Will let you know when I have done more testing
and think it is ready. Any ideas on how to get this functionality as a
standard RPM? I know how to create RPM's but I do not know how to get it
in the distribution.
The fedora website has all the info you need and google can help you find it that info.
I have found some article that may be helpful:
https://fedoraproject.org/wiki/PackageMaintainers/Join
>
> 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;
> >=20
> > dev_read_urand(sshdfilter_t)
> >=20
> > corecmd_search_bin(sshdfilter_t)
> >=20
> > miscfiles_read_localization(sshdfilter_t)
> >=20
> > optional_policy(`
> > iptables_domtrans(sshdfilter_t)
> > ")
> >=20
> > # I would like to see the raw AVC denial for this.
> > # allow sshdfilter_t var_run_t:file getattr;
> >=20
> >>
> >> 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;
> >> ')
> >=20
> > The above looks fine.
> >=20
> >> I'm not getting any avc audit log etries but the script is getting
hun=
> g
> >> 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=
> =2E
> >> So it would appear that the script is not able to run iptables.
> >=20
> > You mean to say that it does not work with the system in permissive mod=
> e (setenforce 0)?
> > If it does not work in permissive mode, then you can rule out any SElin=
> ux related issue.
> >=20
> > If it works in permissive modebut not in enforcing mode then it is a SE=
> linux issue (be aware i mean full permissive mode not permissive domains)=
>
> >=20
> >=20
> >>>
> >>> # 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 ker=
> nel
> >>> 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 it=
> s
> >>> 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 t=
> he
> >>> 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 exte=
> nd
> >>> 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 objec=
> ts
> >>> 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=3D
> >>> )
> >>> /usr/sbin/sshdfilter -- gen_context(system_u:object_r:sshdfilter_exec=
> _t, =3D
> >>> 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 module=
> s.
> >>>
> >>> 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 possi=
> ble
> >>> 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.
> >>>
> >>>> =3D20
> >>>> I'm attaching the down load. It has two methods of installation
so t=
> he
> >>>> files vary depending on approach. I wonder if there would be some
wa=
> y t=3D
> >>> o
> >>>> get this into the repo.