List of operations
by Göran Uddeborg
Maybe this is a FAQ, but I haven't found it answered in any of the
FAQ:s I've looked through:
Is there some kind of documentation list over the available classes
and operations (permissions)?
Other concepts, like types and roles are defined in the policy, with
some luck together with a comment. In some cases there are even
manual pages, like httpd_selinux.
But the list of available classes and operations must be defined by
the kernel module if I understand things correctly. I could extract a
list from the flask/access_vectors file. But I would have liked
something with a sentence or so of explanation. Some names may be
self-explanatory, but many are not obvious. I'm imagining some kind
of list like the appendices of the O'Reilley book, but updated for the
current version. Does such a list exist somewhere? Or is it just in
my imagination? :-)
17 years, 8 months
Re: postfix, procmail and SELinux - No Go
by Paul Howarth
On Tue, 2006-06-06 at 21:34 -0500, Marc Schwartz wrote:
> Paul,
>
> OK...seemingly back up and running. Here are the present avc messages
> since re-loading everything and confirming that the file contexts are
> back to the changes that we made.
>
> I note that the /proc/meminfo messages are back, but now for
> clamassassin. I am sure that I have reloaded the new modules that we
> created, so not sure what is up here, unless there was some conflict
> when the two versions of the policies we seemingly loaded earlier today.
>
> Let me know on these and if perhaps I missed something:
You forgot that we reverted the clamassassin context change yesterday.
# restorecon -v /usr/local/bin/clamassassin
> type=AVC msg=audit(1149646922.456:801): avc: denied { read } for pid=23273 comm="clamassassin" name="meminfo" dev=proc ino=-268435454 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
> type=SYSCALL msg=audit(1149646922.456:801): arch=40000003 syscall=5 success=yes exit=3 a0=489093ef a1=0 a2=1b6 a3=a021240 items=1 pid=23273 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash"
> type=CWD msg=audit(1149646922.456:801): cwd="/home/marcs"
> type=PATH msg=audit(1149646922.456:801): item=0 name="/proc/meminfo" flags=101 inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00
> type=AVC msg=audit(1149646922.456:802): avc: denied { getattr } for pid=23273 comm="clamassassin" name="meminfo" dev=proc ino=-268435454 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
> type=SYSCALL msg=audit(1149646922.456:802): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bf8d7f28 a2=4891eff4 a3=3 items=0 pid=23273 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash"type=AVC_PATH msg=audit(1149646922.456:802): path="/proc/meminfo"
> type=AVC msg=audit(1149646922.456:803): avc: denied { search } for pid=23273 comm="clamassassin" name="bin" dev=hdc7 ino=3112982 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=dir
> type=SYSCALL msg=audit(1149646922.456:803): arch=40000003 syscall=5 success=yes exit=3 a0=a023018 a1=8000 a2=0 a3=8000 items=1 pid=23273 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash"
> type=CWD msg=audit(1149646922.456:803): cwd="/home/marcs"
> type=PATH msg=audit(1149646922.456:803): item=0 name="/usr/local/bin/clamassassin" flags=101 inode=3115337 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
> type=AVC msg=audit(1149646922.460:804): avc: denied { execute } for pid=23274 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
> type=AVC msg=audit(1149646922.460:804): avc: denied { execute_no_trans } for pid=23274 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
> type=AVC msg=audit(1149646922.460:804): avc: denied { read } for pid=23274 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file
> type=SYSCALL msg=audit(1149646922.460:804): arch=40000003 syscall=11 success=yes exit=0 a0=a0232c0 a1=a023500 a2=a026dd0 a3=a023228 items=2 pid=23274 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="mktemp" exe="/bin/mktemp"
> type=AVC_PATH msg=audit(1149646922.460:804): path="/bin/mktemp"
> type=AVC_PATH msg=audit(1149646922.460:804): path="/bin/mktemp"
> type=CWD msg=audit(1149646922.460:804): cwd="/home/marcs"
> type=PATH msg=audit(1149646922.460:804): item=0 name="/bin/mktemp" flags=101 inode=1966111 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00
> type=PATH msg=audit(1149646922.460:804): item=1 flags=101 inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
> type=AVC msg=audit(1149646922.460:805): avc: denied { read } for pid=23274 comm="mktemp" name="urandom" dev=tmpfs ino=1719 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
> type=SYSCALL msg=audit(1149646922.460:805): arch=40000003 syscall=5 success=yes exit=3 a0=80494d8 a1=0 a2=48920120 a3=8f5f008 items=1 pid=23274 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="mktemp" exe="/bin/mktemp"
> type=CWD msg=audit(1149646922.460:805): cwd="/home/marcs"
> type=PATH msg=audit(1149646922.460:805): item=0 name="/dev/urandom" flags=101 inode=1719 dev=00:0f mode=020444 ouid=0 ogid=0 rdev=01:09
> type=AVC msg=audit(1149646922.468:806): avc: denied { execute_no_trans } for pid=23277 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file
> type=SYSCALL msg=audit(1149646922.468:806): arch=40000003 syscall=11 success=yes exit=0 a0=a026c00 a1=a026210 a2=a026dd0 a3=a026d90 items=2 pid=23277 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamscan" exe="/usr/bin/clamscan"
> type=AVC_PATH msg=audit(1149646922.468:806): path="/usr/bin/clamscan"
> type=CWD msg=audit(1149646922.468:806): cwd="/home/marcs"
> type=PATH msg=audit(1149646922.468:806): item=0 name="/usr/bin/clamscan" flags=101 inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
> type=PATH msg=audit(1149646922.468:806): item=1 flags=101 inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00
The context change should fix all of the above.
> type=AVC msg=audit(1149646926.516:807): avc: denied { recv_msg } for saddr=66.250.40.33 src=24441 daddr=192.168.1.2 dest=32875 netif=eth0 scontext=user_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:pyzor_port_t:s0 tclass=udp_socket
Hmm, pyzor needs to receive messages as well as send them...
> type=AVC msg=audit(1149646926.528:808): avc: denied { create } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1149646926.528:808): arch=40000003 syscall=102 success=yes exit=3 a0=1 a1=bfb89868 a2=4891eff4 a3=8069fbf items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKETCALL msg=audit(1149646926.528:808): nargs=3 a0=10 a1=3 a2=0
> type=AVC msg=audit(1149646926.528:809): avc: denied { bind } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1149646926.528:809): arch=40000003 syscall=102 success=yes exit=0 a0=2 a1=bfb89868 a2=4891eff4 a3=3 items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKADDR msg=audit(1149646926.528:809): saddr=100000000000000000000000
> type=SOCKETCALL msg=audit(1149646926.528:809): nargs=3 a0=3 a1=bfb89874 a2=c
> type=AVC msg=audit(1149646926.528:810): avc: denied { getattr } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1149646926.528:810): arch=40000003 syscall=102 success=yes exit=0 a0=6 a1=bfb89868 a2=4891eff4 a3=3 items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKETCALL msg=audit(1149646926.528:810): nargs=3 a0=3 a1=bfb89874 a2=bfb89880
> type=AVC msg=audit(1149646926.528:811): avc: denied { write } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=AVC msg=audit(1149646926.528:811): avc: denied { nlmsg_read } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1149646926.528:811): arch=40000003 syscall=102 success=yes exit=20 a0=b a1=bfb887b4 a2=4891eff4 a3=ffffffcc items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKADDR msg=audit(1149646926.528:811): saddr=100000000000000000000000
> type=SOCKETCALL msg=audit(1149646926.528:811): nargs=6 a0=3 a1=bfb8982c a2=14 a3=0 a4=bfb89840 a5=c
> type=AVC msg=audit(1149646926.528:812): avc: denied { read } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket
> type=SYSCALL msg=audit(1149646926.528:812): arch=40000003 syscall=102 success=yes exit=128 a0=11 a1=bfb887b4 a2=4891eff4 a3=ffffffcc items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc"
> type=SOCKETCALL msg=audit(1149646926.528:812): nargs=3 a0=3 a1=bfb89810 a2=0
I've seen a lot of these recently. I think dcc is trying to read the
routing table. We'll allow that.
(snip)
The rest seem to be duplicates.
Updated policy modules:
####### mydcc.te #######
policy_module(mydcc, 0.1.3)
require {
type spamd_t;
}
type dcc_var_t;
files_type(dcc_var_t)
type dcc_client_map_t;
files_type(dcc_client_map_t)
# Allow spamd to behave as a dcc client
allow spamd_t dcc_client_map_t:file rw_file_perms;
allow spamd_t dcc_var_t:dir search;
# Allow spamd to read the routing table (needed by dcc)
allow spamd_t self:netlink_route_socket { r_netlink_socket_perms };
####### mypyzor.te #######
policy_module(mypyzor, 0.1.3)
require {
type pyzor_t;
type pyzor_port_t;
type spamd_t;
};
# temp files
type pyzor_tmp_t;
files_tmp_file(pyzor_tmp_t)
# Allow pyzor to create and use temp files and dirs
allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
allow pyzor_t pyzor_tmp_t:file create_file_perms;
files_type(pyzor_tmp_t)
files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
# Allow pyzor to read config (and any other file...)
# from user home directories
userdom_read_unpriv_users_home_content_files(pyzor_t)
# Allow pyzor to read /dev/urandom
dev_read_urand(pyzor_t)
# Allow pyzor to send and receive pyzor messages!
allow pyzor_t pyzor_port_t:udp_socket send_msg;
allow pyzor_t pyzor_port_t:udp_socket recv_msg;
# Allow spamd to signal pyzor (kill/hup ?)
allow spamd_t pyzor_t:process signal;
# Allow pyzor to ...?
corecmd_search_bin(pyzor_t)
kernel_read_kernel_sysctls(pyzor_t)
# It does a getattr on /usr/bin/time for reasons unknown...
allow pyzor_t bin_t:dir getattr;
allow pyzor_t bin_t:file getattr;
# Pyzor/python probably doesn't need to be able to read /proc/meminfo
kernel_dontaudit_list_proc(pyzor_t)
kernel_dontaudit_read_system_state(pyzor_t)
Paul.
17 years, 10 months
FC2 useradd in chroot on FC5 host with SELinux
by Paul Howarth
I use mock to build packages for old distributions in a chroot-ed
environment on my FC5 box. I've pretty well got this working for all old
distributions now apart from FC2 (see
http://www.fedoraproject.org/wiki/Legacy/Mock). On FC2, the process gets
off to quite a good start, installing the following packages into the
chroot:
=============================================================================
Package Arch Version Repository
Size
=============================================================================
Installing:
buildsys-build noarch 0.5-1.CF.fc2 groups
1.8 k
Installing for dependencies:
SysVinit i386 2.85-25 core
96 k
basesystem noarch 8.0-3 core
2.7 k
bash i386 2.05b-38 core
1.5 M
beecrypt i386 3.1.0-3 core
64 k
binutils i386 2.15.90.0.3-5 core
2.8 M
buildsys-macros noarch 2-2.fc2 groups
2.1 k
bzip2 i386 1.0.2-12.1 core
48 k
bzip2-libs i386 1.0.2-12.1 core
32 k chkconfig i386 1.3.9-1.1 core
99 k
coreutils i386 5.2.1-7 core
2.8 M
cpio i386 2.5-6 core
45 k
cpp i386 3.3.3-7 core
1.4 M
cracklib i386 2.7-27.1 core
26 k
cracklib-dicts i386 2.7-27.1 core
409 k
db4 i386 4.2.52-3.1 core
1.5 M
dev i386 3.3.13-1 core
3.6 M
diffutils i386 2.8.1-11 core
205 k
e2fsprogs i386 1.35-7.1 core
728 k
elfutils-libelf i386 0.95-2 core
36 k
ethtool i386 1.8-3.1 core
48 k
fedora-release i386 2-4 core
92 k
file i386 4.07-4 core
242 k
filesystem i386 2.2.4-1 core
18 k
findutils i386 1:4.1.7-25 core
102 k
gawk i386 3.1.3-7 core
1.5 M
gcc i386 3.3.3-7 core
3.8 M
gcc-c++ i386 3.3.3-7 core
2.0 M
gdbm i386 1.8.0-22.1 core
26 k
glib i386 1:1.2.10-12.1.1 core
134 k
glib2 i386 2.4.8-1.fc2 updates-released
477 k
glibc i686 2.3.3-27.1 updates-released
4.9 M
glibc-common i386 2.3.3-27.1 updates-released
14 M
glibc-devel i386 2.3.3-27.1 updates-released
1.9 M
glibc-headers i386 2.3.3-27.1 updates-released
530 k
glibc-kernheaders i386 2.4-8.44 core
697 k
grep i386 2.5.1-26 core
168 k
gzip i386 1.3.3-12.2.legacy updates-released
88 k
info i386 4.7-4 updates-released
147 k
initscripts i386 7.55.2-1 updates-released
906 k
iproute i386 2.4.7-14 core
591 k
iputils i386 20020927-13 core
92 k
less i386 382-3 core
85 k
libacl i386 2.2.7-5 core
15 k
libattr i386 2.4.1-4 core
8.6 k
libgcc i386 3.3.3-7 core
33 k
libselinux i386 1.11.4-1 core
45 k
libstdc++ i386 3.3.3-7 core
240 k
libstdc++-devel i386 3.3.3-7 core
1.3 M
libtermcap i386 2.0.8-38 core
12 k
make i386 1:3.80-3 core
337 k
mingetty i386 1.07-2 core
18 k
mktemp i386 2:1.5-7 core
12 k
modutils i386 2.4.26-16 core
395 k
ncurses i386 5.4-5 core
1.5 M
net-tools i386 1.60-25.1 updates-released
311 k
pam i386 0.77-40 core
1.9 M
patch i386 2.5.4-19 core
61 k
pcre i386 4.5-2 core
59 k
perl i386 3:5.8.3-18 core
11 M
perl-Filter i386 1.30-5 core
68 k
popt i386 1.9.1-0.4.1 updates-released
61 k
procps i386 3.2.0-1.2 updates-released
176 k
psmisc i386 21.4-2 core
41 k
redhat-rpm-config noarch 8.0.28-1.1.1 core
41 k
rpm i386 4.3.1-0.4.1 updates-released
2.2 M
rpm-build i386 4.3.1-0.4.1 updates-released
437 k
sed i386 4.0.8-4 core
116 k
setup noarch 2.5.33-1 core
29 k
shadow-utils i386 2:4.0.3-55 updates-released
671 k
sysklogd i386 1.4.1-16 core
65 k
tar i386 1.13.25-14 core
351 k
termcap noarch 11.0.1-18.1 core
237 k
tzdata noarch 2005f-1.fc2 updates-released
449 k
unzip i386 5.50-37 core
139 k
util-linux i386 2.12-19 updates-released
1.5 M
which i386 2.16-2 core
21 k
words noarch 2-22 core
137 k
zlib i386 1.2.1.2-0.fc2 updates-released
44 k
After installing all of these packages successfully, the next thing that
happens is:
Executing /usr/sbin/mock-helper
chroot /var/lib/mock/fedora-2-i386-core/root /bin/su - root -c
"/usr/sbin/useradd -m -u 500 -d /builddir mockbuild"
and at that point the "useradd" process just hangs indefinitely. I'm
told that if SELinux is disabled (I've tried permissive mode and that
doesn't help), this works. I can't see any AVCs in the logs.
Any ideas what might be causing this and how it might be fixed?
Paul.
17 years, 10 months
Running two named processes in selinux
by Faisal Ali
Hi,
Is it possible to run two named process in selinux each having different
file permissions. Instead of using DNS Views Iam thinking about running two
named processes, one for external and one for internal. Ofcourse external
named process will have access to different set of files versus internal
named process.
Can this be done.
Its security-of-Xen-Vm-isolation vs SELinux-isolation comparision.
Should I run two Xen VMs one for external DNS and the other for Internal DNS
or run two named processes each isolated and jailed by SELinux.
Faisal Ali
17 years, 11 months
pam_console_t wants access to device_t:chr_file ?
by Tom London
Running targeted/enforcing, latest Rawhide.
Noticed this in /var/log/messages, before auditd is started I guess:
Jun 29 06:43:48 localhost kernel: audit(1151588567.562:102): avc:
denied { getattr } for pid=1526 comm="pam_console_app"
name="usbdev5.5_ep02" dev=tmpfs ino=5143
scontext=system_u:system_r:pam_console_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
Jun 29 06:43:48 localhost kernel: audit(1151588567.562:103): avc:
denied { getattr } for pid=1526 comm="pam_console_app"
name="usbdev5.5_ep81" dev=tmpfs ino=5120
scontext=system_u:system_r:pam_console_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
Jun 29 06:43:48 localhost kernel: audit(1151588567.562:104): avc:
denied { getattr } for pid=1526 comm="pam_console_app"
name="usbdev5.5_ep00" dev=tmpfs ino=5068
scontext=system_u:system_r:pam_console_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
<< actually many, many copies of these....>>
tom
--
Tom London
17 years, 11 months
dovecot 1.0.rc1
by Paul Howarth
New in rc1 is a directory /var/lib/dovecot where the SSL parameters
files are generated before they are copied to the login directory.
The following additions to policy support this:
::::::::::::::
dovecot.fc
::::::::::::::
/var/lib/dovecot(/.*)?
gen_context(system_u:object_r:dovecot_var_lib_t,s0)
::::::::::::::
dovecot.te
::::::::::::::
policy_module(dovecot, 0.1.4)
########################################
#
# Declarations
#
require {
type dovecot_t;
};
# /var/lib/dovecot holds SSL parameters file
type dovecot_var_lib_t;
files_type(dovecot_var_lib_t)
########################################
#
# Local policy
#
# Allow dovecot to read the routing table (in selinux-policy 2.2.43-4.fc5)
#allow dovecot_t self:netlink_route_socket { r_netlink_socket_perms };
# Allow dovecot to create and read SSL parameters file
files_search_var_lib(dovecot_t)
allow dovecot_t dovecot_var_lib_t:dir { rw_dir_perms };
allow dovecot_t dovecot_var_lib_t:file { manage_file_perms };
Paul.
17 years, 11 months
AVCs when printing from firefox...
by Tom London
Running targeted/enforcing, latest rawhide.
Trying to print from firefox, I get:
type=AVC msg=audit(1151341517.216:697): avc: denied { recv } for
pid=2965 comm="firefox-bin" saddr=127.0.0.1 src=50209 daddr=127.0.0.1
dest=631 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=AVC msg=audit(1151341520.217:698): avc: denied { recv } for
saddr=127.0.0.1 src=50209 daddr=127.0.0.1 dest=631 netif=lo
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=AVC msg=audit(1151341526.217:699): avc: denied { recv } for
saddr=127.0.0.1 src=50209 daddr=127.0.0.1 dest=631 netif=lo
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=AVC msg=audit(1151341538.217:700): avc: denied { recv } for
saddr=127.0.0.1 src=50209 daddr=127.0.0.1 dest=631 netif=lo
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=AVC msg=audit(1151341562.219:701): avc: denied { recv } for
saddr=127.0.0.1 src=50209 daddr=127.0.0.1 dest=631 netif=lo
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
Doing a 'setenforce 0' and retrying yields:
type=AVC msg=audit(1151342357.528:780): avc: denied { recv } for
pid=3943 comm="firefox-bin" saddr=127.0.0.1 src=47782 daddr=127.0.0.1
dest=631 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=AVC msg=audit(1151342357.528:780): avc: denied { send } for
pid=3943 comm="firefox-bin" saddr=127.0.0.1 src=631 daddr=127.0.0.1
dest=47782 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=SYSCALL msg=audit(1151342357.528:780): arch=40000003 syscall=102
success=yes exit=0 a0=3 a1=bfbf8db0 a2=4703c3f4 a3=0 items=0 ppid=3938
pid=3943 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500
sgid=500 fsgid=500 tty=(none) comm="firefox-bin"
exe="/usr/lib/firefox-1.5.0.4/firefox-bin"
subj=user_u:system_r:unconfined_t:s0
type=SOCKADDR msg=audit(1151342357.528:780):
saddr=020002777F0000010000000000000000
type=SOCKETCALL msg=audit(1151342357.528:780): nargs=3 a0=27 a1=b6d875c a2=10
type=AVC msg=audit(1151342370.197:781): avc: denied { send } for
pid=4108 comm="hp" saddr=127.0.0.1 src=43162 daddr=127.0.0.1
dest=50000 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=AVC msg=audit(1151342370.197:781): avc: denied { recv } for
pid=4108 comm="hp" saddr=127.0.0.1 src=43162 daddr=127.0.0.1
dest=50000 netif=lo scontext=system_u:system_r:hplip_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=AVC msg=audit(1151342370.197:781): avc: denied { send } for
pid=4108 comm="hp" saddr=127.0.0.1 src=50000 daddr=127.0.0.1
dest=43162 netif=lo scontext=system_u:system_r:hplip_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=AVC msg=audit(1151342370.197:781): avc: denied { recv } for
pid=4108 comm="hp" saddr=127.0.0.1 src=50000 daddr=127.0.0.1
dest=43162 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet
type=SYSCALL msg=audit(1151342370.197:781): arch=40000003 syscall=102
success=yes exit=0 a0=3 a1=bf86ac50 a2=804d110 a3=804d1a4 items=0
ppid=2246 pid=4108 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4
egid=7 sgid=7 fsgid=7 tty=(none) comm="hp"
exe="/usr/lib/cups/backend/hp"
subj=system_u:system_r:cupsd_t:s0-s0:c0.c255
type=SOCKADDR msg=audit(1151342370.197:781):
saddr=0200C3507F0000010000000000000000
type=SOCKETCALL msg=audit(1151342370.197:781): nargs=3 a0=4 a1=bf86ac78 a2=10
tom
--
Tom London
17 years, 11 months
Openswan on FC4/5
by Stuart James
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
We are using Openswan to connect two of our sites together via an IPSEC
tunnel. Recently we upgraded from FC3 to FC5 on our frontend firewalls,
including the version of openswan , selinux policy, kernel ,ect. We used
to run in enforcing mode without any difficulties, it now seems that
with Enforcing mode on Openswan does not seem to be able to add the
route.
Using setenforce 0 , the tunnel becomes active. As far as i can
tell Openswan has difficulty adding the route to the Right/Left nexthop,
although the status of the tunnel appears to be up, the routing does not
appear to take place.
#audit2allow -a -t /var/log/audit/audit.log
allow ifconfig_t self:netlink_xfrm_socket create;
allow ifconfig_t initrc_t:unix_stream_socket { read write };
Versions we are using are.
selinux-policy-targeted-2.2.43-4.fc5
kernel-2.6.16-1.2122_FC5
openswan-2.4.4-1.1.2.1
As i have not seen any other mention of this being an issue, I was
wondering if anyone else has encountered this. I have also tested this
on FC4 with the same result.
Am i right in assuming that openswan is using ifconfig to add the
route, i have looked into the source policy that define ipsec which has
no reference to ifconfig, but rather to ipsec eroute.
I am not sure if this just defined in the wrong place, or if it needs
ifconfig to be added into the policy.
Regards,
Stuart James
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEn5lKr8LwOCpshrYRAr+gAJ9y7uL7WOco3Pxj4gg0gWlrqhGRIQCeLIFu
Cfnub95XnvCsMRwxI9ojSek=
=dXrv
-----END PGP SIGNATURE-----
17 years, 11 months
RE: Running two named processes in selinux
by Paul Howarth
On Fri, 2006-06-30 at 16:15 -0400, Faisal Ali wrote:
> Yes, exactly to run named in different SELinux domains. Iam glad its doable,
> do you mean use the canned policy for one named and create a new one for
> another named process. Can you point me to any read on the web that can help
> in doing this.
Can't think of any offhand. The approach I'd take would be to get the
SELinux SRPM and "prep" it to get all the patches applied, then find the
bind policy module and make a copy of it, and then edit all of the
named_* types to have another name (e.g. other_named_*). Change the file
contexts to refer to the locations and new type names you're using, then
try building and loading the new module and see how it goes.
Of course, I'd get the two-daemon thing working without SELinux (or with
the same policy for each) first.
> I guess its more of comfort level thing, I know BIND9 is quite secure and I
> have'nt heard of any hacks. But if it happens then hacker can have
> visibility to internal hosts information.
True, but is that such a big deal? It might give a clue to where to
start looking for targets but if they can get into your network they
could probably figure that out anyway by portscanning.
Paul.
17 years, 11 months
Running two named processes in selinux
by Faisal Ali
Hi,
Is it possible to run two named process in selinux each having different
file permissions. Instead of using DNS Views Iam thinking about running two
named processes, one for external and one for internal. Ofcourse external
named process will have access to different set of files versus internal
named process.
Can this be done.
Faisal Ali
17 years, 11 months
