Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora SELinux Support (http://www.linux-archive.org/fedora-selinux-support/)
-   -   Need new secret sauce (http://www.linux-archive.org/fedora-selinux-support/367127-need-new-secret-sauce.html)

David Highley 05-06-2010 01:32 PM

Need new secret sauce
 
Did the usual dance after selinux policy seemed to get wiped out. Does
not appear to be working. I also did an semodule -r mysshdfilter just to
make sure there was not some thing fouled up.

grep sshdfilter /var/log/audit/audit.log | tail -2 | audit2allow -M
mysshdfilter

semodule -i mysshdfilter.pp


type=SYSCALL msg=audit(1273152205.754:30341): arch=c000003e syscall=2
success=no exit=-13 a0=1f16088 a1=241 a2=1b6 a3=7f26f5e60920 items=0
ppid=24925 pid=24926 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=731 comm="sshdfilter" exe="/usr/bin/perl"
subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1273152205.754:30341): avc: denied { write } for
pid=24926 comm="sshdfilter" name="sshdfilter.pid.SSHD" dev=dm-0 ino=539
scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_run_t:s0 tclass=file
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

David Highley 05-07-2010 03:35 AM

Need new secret sauce
 
Did the usual dance after selinux policy seemed to get wiped out. Does
not appear to be working. I also did an semodule -r mysshdfilter just to
make sure there was not some thing fouled up.

grep sshdfilter /var/log/audit/audit.log | tail -2 | audit2allow -M
mysshdfilter

semodule -i mysshdfilter.pp


type=SYSCALL msg=audit(1273152205.754:30341): arch=c000003e syscall=2
success=no exit=-13 a0=1f16088 a1=241 a2=1b6 a3=7f26f5e60920 items=0
ppid=24925 pid=24926 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=731 comm="sshdfilter" exe="/usr/bin/perl"
subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1273152205.754:30341): avc: denied { write } for
pid=24926 comm="sshdfilter" name="sshdfilter.pid.SSHD" dev=dm-0 ino=539
scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:var_run_t:s0 tclass=file
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

Dominick Grift 05-07-2010 10:05 AM

Need new secret sauce
 
On Thu, May 06, 2010 at 08:35:25PM -0700, David Highley wrote:
> Did the usual dance after selinux policy seemed to get wiped out. Does
> not appear to be working. I also did an semodule -r mysshdfilter just to
> make sure there was not some thing fouled up.
>
> grep sshdfilter /var/log/audit/audit.log | tail -2 | audit2allow -M
> mysshdfilter
>
> semodule -i mysshdfilter.pp
>
>
> type=SYSCALL msg=audit(1273152205.754:30341): arch=c000003e syscall=2
> success=no exit=-13 a0=1f16088 a1=241 a2=1b6 a3=7f26f5e60920 items=0
> ppid=24925 pid=24926 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=(none) ses=731 comm="sshdfilter" exe="/usr/bin/perl"
> subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
> type=AVC msg=audit(1273152205.754:30341): avc: denied { write } for
> pid=24926 comm="sshdfilter" name="sshdfilter.pid.SSHD" dev=dm-0 ino=539
> scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:var_run_t:s0 tclass=file


Looks like this app may need policy. I could not find a sshdfilter package in the regular fedora repositories though.

The fact of the matter is that /var/run/sshdfilter.pid.SSHD somehow is mislabeled, and that sshd_t cannot access the mislabeled pid file.

In some cases using audit2allow to allow stuff is a bad idea. This is one such example.

The problem needs to be solved at it core. We need to figure out why and when the pid was mislabeled and make sure it instead gets a proper label.


> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

David Highley 05-07-2010 01:31 PM

Need new secret sauce
 
"Dominick Grift wrote:"
>
> On Thu, May 06, 2010 at 08:35:25PM -0700, David Highley wrote:
> > Did the usual dance after selinux policy seemed to get wiped out. Does
> > not appear to be working. I also did an semodule -r mysshdfilter just to
> > make sure there was not some thing fouled up.
> >=20
> > grep sshdfilter /var/log/audit/audit.log | tail -2 | audit2allow -M
> > mysshdfilter
> >=20
> > semodule -i mysshdfilter.pp
> >=20
> >=20
> > type=3DSYSCALL msg=3Daudit(1273152205.754:30341): arch=3Dc000003e syscall=
> =3D2
> > success=3Dno exit=3D-13 a0=3D1f16088 a1=3D241 a2=3D1b6 a3=3D7f26f5e60920 =
> items=3D0
> > ppid=3D24925 pid=3D24926 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fs=
> uid=3D0 egid=3D0
> > sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D731 comm=3D"sshdfilter" exe=3D"/usr=
> /bin/perl"
> > subj=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null)
> > type=3DAVC msg=3Daudit(1273152205.754:30341): avc: denied { write } for
> > pid=3D24926 comm=3D"sshdfilter" name=3D"sshdfilter.pid.SSHD" dev=3Ddm-0 i=
> no=3D539
> > scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> > tcontext=3Dsystem_u:object_r:var_run_t:s0 tclass=3Dfile
>
>
> Looks like this app may need policy. I could not find a sshdfilter package =
> in the regular fedora repositories though.
>
> The fact of the matter is that /var/run/sshdfilter.pid.SSHD somehow is misl=
> abeled, and that sshd_t cannot access the mislabeled pid file.
>
> In some cases using audit2allow to allow stuff is a bad idea. This is one s=
> uch example.
>
> The problem needs to be solved at it core. We need to figure out why and wh=
> en the pid was mislabeled and make sure it instead gets a proper label.

Yes, it would be nice to have this application show up as a standard
package. It makes it easy to tighten up outside secure shell access. The
software comes from http://www.cs.liv.ac.uk/~greg/sshdfilter/

It is a Perl script and a configuration file. It wraps around sshd to
give you the ability to deny access to login accounts, it detects ping
probes and break in attempts and dynamically creates iptable rules to
block sites. It ages the rules and drops them back out after
configurable time periods.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

Dominick Grift 05-07-2010 01:36 PM

Need new secret sauce
 
On Fri, May 07, 2010 at 06:31:52AM -0700, David Highley wrote:
> "Dominick Grift wrote:"
> >
> > On Thu, May 06, 2010 at 08:35:25PM -0700, David Highley wrote:
> > > Did the usual dance after selinux policy seemed to get wiped out. Does
> > > not appear to be working. I also did an semodule -r mysshdfilter just to
> > > make sure there was not some thing fouled up.
> > >=20
> > > grep sshdfilter /var/log/audit/audit.log | tail -2 | audit2allow -M
> > > mysshdfilter
> > >=20
> > > semodule -i mysshdfilter.pp
> > >=20
> > >=20
> > > type=3DSYSCALL msg=3Daudit(1273152205.754:30341): arch=3Dc000003e syscall=
> > =3D2
> > > success=3Dno exit=3D-13 a0=3D1f16088 a1=3D241 a2=3D1b6 a3=3D7f26f5e60920 =
> > items=3D0
> > > ppid=3D24925 pid=3D24926 auid=3D1000 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fs=
> > uid=3D0 egid=3D0
> > > sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D731 comm=3D"sshdfilter" exe=3D"/usr=
> > /bin/perl"
> > > subj=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=3D(null)
> > > type=3DAVC msg=3Daudit(1273152205.754:30341): avc: denied { write } for
> > > pid=3D24926 comm=3D"sshdfilter" name=3D"sshdfilter.pid.SSHD" dev=3Ddm-0 i=
> > no=3D539
> > > scontext=3Dunconfined_u:system_r:sshd_t:s0-s0:c0.c1023
> > > tcontext=3Dsystem_u:object_r:var_run_t:s0 tclass=3Dfile
> >
> >
> > Looks like this app may need policy. I could not find a sshdfilter package =
> > in the regular fedora repositories though.
> >
> > The fact of the matter is that /var/run/sshdfilter.pid.SSHD somehow is misl=
> > abeled, and that sshd_t cannot access the mislabeled pid file.
> >
> > In some cases using audit2allow to allow stuff is a bad idea. This is one s=
> > uch example.
> >
> > The problem needs to be solved at it core. We need to figure out why and wh=
> > en the pid was mislabeled and make sure it instead gets a proper label.
>
> Yes, it would be nice to have this application show up as a standard
> package. It makes it easy to tighten up outside secure shell access. The
> software comes from http://www.cs.liv.ac.uk/~greg/sshdfilter/
>
> It is a Perl script and a configuration file. It wraps around sshd to
> give you the ability to deny access to login accounts, it detects ping
> probes and break in attempts and dynamically creates iptable rules to
> block sites. It ages the rules and drops them back out after
> configurable time periods.

Can you enclose a list of the files this package includes and their location on the file system?
If it wraps around sshd then you could probably label the sshdfilter executable file with the sshd executable file type and then extend the sshd_t domain to allow it the access it needs and define type transitions where required.

> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

Dominick Grift 05-10-2010 08:37 AM

Need new secret sauce
 
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_ex ec_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.


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

Dominick Grift 05-16-2010 08:51 AM

Need new secret sauce
 
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;

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_ex ec_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.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

Dominick Grift 05-16-2010 10:17 AM

Need new secret sauce
 
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_ex ec_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.


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

Dominick Grift 05-17-2010 08:48 AM

Need new secret sauce
 
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_ex ec_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.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux


All times are GMT. The time now is 08:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.