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