rhel6 beta mls enforcing seeing lots of these ...
by Ted Toth
type=AVC msg=audit(1273678015.579:14138): avc: denied { connectto }
for pid=1073 comm="sedispatch" path="/var/run/dbus/system_bus_socket"
scontext=system_u:system_r:audisp_t:s15:c0.c1023
tcontext=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023
tclass=unix_stream_socket
Ted
14 years
Fwd: talking to mcstrans in MLS enforcing on rhel6 beta
by Ted Toth
---------- Forwarded message ----------
From: Xavier Toth <txtoth(a)gmail.com>
Date: Wed, May 12, 2010 at 10:38 AM
Subject: Re: talking to mcstrans in MLS enforcing on rhel6 beta
To: Stephen Smalley <sds(a)tycho.nsa.gov>
On Tue, May 11, 2010 at 4:13 PM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
> On Tue, 2010-05-11 at 11:10 -0500, Xavier Toth wrote:
>> I'm a bit confused about something. mcstransd creates a socket and
>> through a transition rule it get labeled setrans_var_run_t (this is
>> also the type used with mls_trusted_object in the setrans policy)
>> however when other apps try and connect to it the target context type
>> is setrans_t which of course isn't trusted so no one can connect. As
>> an experiment I added setrans_t as a mls trusted object and then other
>> apps could connect. Not sure where the target context comes from on
>> connectto because the socket file is label setrans_var_run_t on the
>> disk. Something needs fixing just not sure what. Doesn't seem right to
>> add 'mls_trusted_object(setrans_t)'.
>
> When you create and bind a Unix domain socket in the file system
> namespace (as opposed to the abstract namespace), there are two objects:
> the socket itself (created upon the socket call, labeled with the label
> of the creating process), and the file (created upon the bind call,
> labeled in accordance with the usual file labeling behavior).
> Connecting to such a socket requires both write access to the file and
> connectto permission to the socket. So connectto is a socket-to-socket
> (which looks like process-to-process since sockets are labeled based on
> creating process and act as proxies/queues between processes) check.
>
> --
> Stephen Smalley
> National Security Agency
>
>
So mls_trusted_object(setrans_t) needs to be added.
14 years
talking to mcstrans in MLS enforcing on rhel6 beta
by Ted Toth
I'm a bit confused about something. mcstransd creates a socket and
through a transition rule it get labeled setrans_var_run_t (this is
also the type used with mls_trusted_object in the setrans policy)
however when other apps try and connect to it the target context type
is setrans_t which of course isn't trusted so no one can connect. As
an experiment I added setrans_t as a mls trusted object and then other
apps could connect. Not sure where the target context comes from on
connectto because the socket file is label setrans_var_run_t on the
disk. Something needs fixing just not sure what. Doesn't seem right to
add 'mls_trusted_object(setrans_t)'.
Ted
14 years
Re: Need new secret sauce
by Dominick Grift
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_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.
>
> 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.
14 years
Need new secret sauce
by David Highley
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
14 years
Need new secret sauce
by David Highley
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
14 years
about selinux_validate_context
by Sandra Rueda
Hello,
I am getting the following rule in my SELinux policy:
allow user_t security_t:file {read write};
I traced it and I found the interface selinux_validate_context grants permissions to read and write files with type security_t.
Are these permissions required to validate a security context?
Should they be granted to user_t?
Thanks,
Sandra
14 years
Apache CGI scripts - how to run them cleanly
by Lars Poulsen
I am trying to get my Fedora 12 systems to run cleanly with SELinux
enabled. Previously I had just been running in permissive mode and
mostly ignoring the alerts, but my ambition level has gone up!
After a few days of following up on every alert I saw by tweaking
booleans and file context types appropriately, I am pleased with how
few violations are being reported, but I am now getting to some that
I cannot figure out, such as the one below.
It originates in a CGI script written in PERL. In my installations,
the base of the website data is in /home/httpd rather than in
/var/www; this choice is because I try to keep permanent data that
should be kept across OS version updates out of the root filesystem,
and the website is too small to merit a filesystem of its own. It
does mean that I need to tweek a bunch of labels, such as
* setsebool -P httpd_read_user_content 1
* setsebool -P httpd_enable_home_dirs 1
* setsebool -P httpd_read_user_content 1
* setsebool -P samba_enable_home_dirs 1
* setsebool -P use_samba_home_dirs 1
* setsebool -P samba_export_all_rw 1
*
* chcon -R -t httpd_user_content_t /var/log/phone
* chcon -R -t httpd_user_content_t /home/httpd/twiki/data
* chcon -R -t httpd_sys_script_exec_t /home/httpd/twiki/bin
* chcon -R -t httpd_sys_script_exec_t /home/httpd/cgi-bin
* chcon -t httpd_sys_content_t /home/httpd
* chcon -R -t httpd_sys_content_t /home/httpd/html
* chcon -R -t httpd_user_content_t /home/sales/serial
* chcon -R -t htppd_user_content_t /home/sales/leads
But the one that baffles me the most is this one, which comes up when
I trigger the CGI script /home/httpd/cgi-bin/serial.cgi (written in PERL).
I *think* the "search" access is triggered when the script is launched.
SELinux says that / is labeled as user_home_dir_t, but this is not
true; ls -Zd confirms that it is indeed labeled as root_t. And even
if it were labeled user_homme_dir_t, should the boolean
httpd_enable_home_dirs not make it allright ?
Any insights would be appreciated.
Lars Poulsen
Afar Communications
-------------------------------------------------------------------------------------------------------------------------
Summary:
SELinux is preventing /usr/bin/perl "search" access to /.
Detailed Description:
[SELinux is in permissive mode. This access was not denied.]
SELinux denied access requested by serial.cgi. / may be a mislabeled. / default
SELinux type is root_t, but its current type is user_home_dir_t. Changing this
file back to the default type, may fix your problem.
File contexts can be assigned to a file in the following ways.
* Files created in a directory receive the file context of the parent
directory by default.
* The SELinux policy might override the default label inherited from the
parent directory by specifying a process running in context A
which creates
a file in a directory labeled B will instead create the file with label C.
An example of this would be the dhcp client running with the
dhclient_t type
and creating a file in the directory /etc. This file would
normally receive
the etc_t type due to parental inheritance but instead the file is labeled
with the net_conf_t type because the SELinux policy specifies this.
* Users can change the file context on a file using tools such as chcon, or
restorecon.
This file could have been mislabeled either by user error, or if an normally
confined application was run under the wrong domain.
However, this might also indicate a bug in SELinux because the file should not
have been labeled with this type.
If you believe this is a bug, please file a bug report against this package.
Allowing Access:
You can restore the default system context to this file by executing the
restorecon command. restorecon '/', if this file is a directory, you can
recursively restore using restorecon -R '/'.
Fix Command:
/sbin/restorecon '/'
Additional Information:
Source Context system_u:system_r:httpd_sys_script_t:s0
Target Context unconfined_u:object_r:user_home_dir_t:s0
Target Objects / [ dir ]
Source serial.cgi
Source Path /usr/bin/perl
Port <Unknown>
Host shadow.afar.net
Source RPM Packages perl-5.10.0-87.fc12
Target RPM Packages filesystem-2.4.30-2.fc12
Policy RPM selinux-policy-3.6.32-113.fc12
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Plugin Name restorecon
Host Name shadow.afar.net
Platform Linux shadow.afar.net 2.6.32.11-99.fc12.i686.PAE
#1 SMP Mon Apr 5 16:15:03 EDT 2010 i686 i686
Alert Count 6
First Seen Tue 04 May 2010 10:27:30 AM PDT
Last Seen Tue 04 May 2010 11:15:28 AM PDT
Local ID 6cee89bd-3559-4483-9802-fa2dc320bd26
Line Numbers
Raw Audit Messages
node=shadow.afar.net type=AVC msg=audit(1272996928.152:22292):
avc: denied { search } for pid=15632 comm="serial.cgi" name="/"
dev=dm-7 ino=2 scontext=system_u:system_r:httpd_sys_script_t:s0
tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
node=shadow.afar.net type=SYSCALL msg=audit(1272996928.152:22292):
arch=40000003 syscall=5 success=yes exit=3 a0=8b6767c a1=8000 a2=0
a3=0 items=0 ppid=31549 pid=15632 auid=4294967295 uid=48 gid=489
euid=48 suid=48 fsuid=48 egid=489 sgid=489 fsgid=489 tty=(none)
ses=4294967295 comm="serial.cgi" exe="/usr/bin/perl"
subj=system_u:system_r:httpd_sys_script_t:s0 key=(null)
14 years
SELinux preventing printing.
by Steve Blackwell
My wife got a Lexmark X2670 printer with her new laptop and I connected
it to my Fedora 11 system, and downloaded the driver from Lexmark.
SELinux is preventing me from printing to it. At first I got 4 AVCs
about attempting to load shared libraries that require text relocation.
This I fixed with:
# semanage fcontext -a -t textrel_shlib_t
'/usr/local/lexmark/lxk08/lib(/.*)?'
# restorecon -R -v /usr/local/lexmark/lxk08/lib
but now I'm getting this one:
Raw Audit Messages :
node=steve.blackwell type=AVC
msg=audit(1272894966.836:66): avc: denied { search } for pid=29536
comm="printdriver" name="lib" dev=dm-0 ino=7635564
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:textrel_shlib_t:s0 tclass=dir
node=steve.blackwell type=SYSCALL msg=audit(1272894966.836:66):
arch=40000003 syscall=5 success=no exit=-13 a0=93cf620 a1=0 a2=0
a3=389660 items=0 ppid=1655 pid=29536 auid=4294967295 uid=4 gid=7
euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=4294967295
comm="printdriver" exe="/usr/local/lexmark/lxk08/bin/printdriver"
subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null)
What is the "correct" way to solve this? Create am audit2allow rule?
Thanks,
Steve
14 years
Mod-security (mlogc) problem
by Arthur Dent
Hello all,
I believe in a multi-layered approach towards security, so as well as
SELinux I use Mod-Security to protect the web server on my F11 machine.
Recently I started using the ModSecurity Community Console to analyse
the mod-security denials. This requires using the mlogc logging
application that comes bundled with the mod_security-2.5.12-1.fc11.i586
package.
Now every time a mod-security denial is triggered I get 3 SEL AVCs
(currently in permissive mode while I sort this out). They say:
SELinux has denied the mlogc access to potentially mislabeled files /var/run/pcscd.pid. This means that SELinux will not allow httpd to use these files. Many third party apps install html files in directories that SELinux policy cannot predict. These directories have to be labeled with a file context which httpd can access.
If you want to change the file context of /var/run/pcscd.pid so that the
httpd daemon can access it, you need to execute it using chcon -t
httpd_sys_content_t '/var/run/pcscd.pid'.
A similar one for /var/run/pcsd.pub
and then one for:
SELinux is preventing the mlogc from using potentially mislabeled files
636F6F6C6B6579706B313173452D47617465203020302D30 (auth_cache_t).
(Actual AVCs below)
If I try doing the chcon -t httpd_sys_content_t '/var/run/pcscd.xxx' as
recommended by sealert I only get the one with the strange filename each
time I get a mod-sec alert. However, now of course I get this:
SELinux denied access requested by certwatch. /var/run/pcscd.pub may be a mislabeled. /var/run/pcscd.pub default SELinux type is pcscd_var_run_t, but its current type is httpd_sys_content_t. Changing this file back to the default type, may fix your problem.
(and another one for .pid)
So I need to put the file context back to what it was using
restorecon....
Audit2allow suggests this:
require {
type auth_cache_t;
type httpd_t;
type pcscd_var_run_t;
class file { read write getattr open };
}
#============= httpd_t ==============
allow httpd_t auth_cache_t:file { read write };
allow httpd_t pcscd_var_run_t:file { read getattr open };
What do you think is the best solution to this problem?
Thanks in advance for any help or suggestions...
Mark
AVCs
====
Raw Audit Messages :
node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { read } for pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { open } for pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270480904.700:37928): arch=40000003 syscall=5 success=yes exit=10 a0=d348ea a1=0 a2=1b6 a3=d348e8 items=0 ppid=9643 pid=9674 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
Raw Audit Messages :
node=troodos.org.uk type=AVC msg=audit(1270488357.977:38184): avc: denied { getattr } for pid=10531 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270488357.977:38184): arch=40000003 syscall=195 success=yes exit=0 a0=d345ab a1=b64279ac a2=d1eff4 a3=3 items=0 ppid=9643 pid=10531 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
Raw Audit Messages :
node=troodos.org.uk type=AVC msg=audit(1270488685.640:38200): avc: denied { read write } for pid=10661 comm="mlogc" name=636F6F6C6B6579706B313173452D47617465203020302D30 dev=sda5 ino=372384 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:auth_cache_t:s0 tclass=file
node=troodos.org.uk type=SYSCALL msg=audit(1270488685.640:38200): arch=40000003 syscall=5 success=yes exit=12 a0=b5830dc0 a1=20002 a2=180 a3=b5830da8 items=0 ppid=10644 pid=10661 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
14 years
