Selinux Troubleshoot Browser at login
by David Highley
Since the most recent update of the selinux policies:
Jan 29 06:05:50 Updated: setroubleshoot-plugins-2.1.37-1.fc12.noarch
Jan 29 06:05:52 Updated: setroubleshoot-server-2.2.60-1.fc12.x86_64
Jan 29 06:05:53 Updated: setroubleshoot-2.2.60-1.fc12.x86_64
The browser pops up on every login indicating that there are two events.
Open the browser and nothing is listed.
Question, as part of the move of the email lists from Red Hat did the
bug reporting also move? My account at bugzilla.redhat.com is now gone.
So where do we now report Fedora bugs?
--
Regards,
David Highley
14 years, 2 months
- 2
- 7
dbus daemon
by Steve Blackwell
I have been getting alot of AVCs that are related to dbus. A quick check
shows that I have 2 dbus daemons running.
$ ps aux | grep dbus
dbus 1615 0.0 0.1 14160 1880 ? Ssl 11:53 0:01
dbus-daemon --system
gdm 2385 0.0 0.0 3312 580 ? S 11:54
0:00 /usr/bin/dbus-launch --exit-with-session
steve
2650 0.0 0.0 3312 576 ? S 11:58 0:00 dbus-launch
--sh-syntax --exit-with-session
steve 2652 0.1 0.1 13528 1484 ? Ssl 11:58
0:01 /bin/dbus-daemon --fork --print-pid 7 --print-address 9 --session
steve 3154 0.0 0.0 4192 708 pts/0 S+ 12:16 0:00 grep
dbus
The one that is owned by dbus has a system_u:system_r:system_dbusd_t
context.
The one that is owned by me has a unconfined_u:unconfined_r:unconfined_t
context.
First question: should I really have 2 dbus-daemons?
One AVC says that the dbus daemon owned by dbus can't search
unconfined_t. It was trying to search /proc/2963 which was the
gpk-update-viewer which was running unconfined. (I'm running SELinux in
permissive mode)
$ ps -efZ | grep 2964
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 steve 2963 1 3
12:05 ? 00:00:07 gpk-update-viewer
Second question: does dbus have any reason to look at gpk-update
viewer?
Clearly, it needs to record the fact that the system was updated but
why does it need to check the update viewer for that?
Last question: how do I fix this? I don't have any modified or
additional SELinux policies so I would have thought this would work
"out-of-the-box".
Here is the raw audit message:
node=steve.blackwell type=AVC msg=audit(1264871141.507:132): avc:
denied { search } for pid=1615 comm="dbus-daemon" name="2963" dev=proc
ino=17982 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=dir
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: targeted
$ rpm -qa | grep selinux
libselinux-2.0.80-1.fc11.i586
selinux-policy-targeted-3.6.12-93.fc11.noarch
libselinux-utils-2.0.80-1.fc11.i586
libselinux-devel-2.0.80-1.fc11.i586
libselinux-python-2.0.80-1.fc11.i586
selinux-policy-3.6.12-93.fc11.noarch
Thanks,
Steve
14 years, 2 months
- 2
- 1
Re: Assigning a Type to Network Interfaces
by Jason Shaw
Here is what I found. Using netlabelctl, I could successfully restrict all
inbound/outbound network access to the system on a specific interface. I
could then permit only SSH into the system via allow rules associated with
the peer label assigned using netlabelctl unlbl.That worked great. In fact,
I'm really excited to explore other possibilities using netlabelctl as it
has many valuable possible uses.
However, I found that my test app (with the allow rule below), could still
read and display packet data coming in on any interface even with all
interfaces assigned a unique peer_t using netlabelctl unlbl add. This was
true when no explicit allow rules were added for the test app (running in
myAPP_t). So while netlabelctl did require explicit allow rules for SSH to
send/receive data (I beleive for sshd_t), an allow rule was not required to
read raw data off of the interface for myAPP_t.
allow myApp_t self:packet_socket { create read bind ioctl };
My understanding is that a packet socket is read at the device driver level.
As such, is it possible that the packet socket is being read before
netlabelctl enforcements are taking place?
On Tue, Jan 19, 2010 at 3:54 PM, Paul Moore <paul.moore(a)hp.com> wrote:
> On Tuesday 19 January 2010 01:07:53 pm Jason Shaw wrote:
> > Can netif checks be enabled for 'packet_socket read'? If so, how?
> >
> > My app requires this allow rule:
> > allow myApp_t self:packet_socket { create read bind ioctl };
> >
> > Currently, with this rule in place and the app running in its own
> > domain, it can read data from any interface. If I am understanding
> > correclty, with a netif-based check enabled for packet_socket read, could
> > the application then be restricted to read from a specific eth interface
> > as opposed to being able read from any eth interface?
>
> The ingress/egress and secmark controls should work regardless of the
> socket
> type, so there _should_ be no problem with packet sockets. Assuming you
> want to use the ingress/egress controls you would need to do the following:
>
> 1. Ensure you have the right policy loaded
>
> For the examples shown here you will need to create two new types,
> "foo_netif_t" and "foo_peer_t", as well as the policy rules to allow
> them to work. Stephen has already pointed you to some blog entries
> explaining what you need to do, so we'll consider this step as an
> exercise for the reader :)
>
> 2. Label the interface
>
> You've already got this figured out for the most part, but for the
> record, the following will assign type "foo_netif_t" to eth0 and
> display the configured interface labels:
>
> # semanage interface -a -t foo_netif_t eth0
> # semanage interface -l
>
> 3. Configure a static network peer label (assumes unlabeled traffic)
>
> If you aren't using a form of network peer labeling, e.g. labeled
> IPsec or CIPSO, you'll need to enable some form of per-packet
> peer labeling for the controls to take effect (otherwise the
> packets are unlabeled and the controls just don't make sense).
> In order to configure a static network peer label you need to ensure
> that you have "netlabelctl" installed:
>
> # yum install netlabel_tools
>
> From here you should read the netlabelctl man page (lots of good
> examples) and then come back to this email ... I'll wait .... okay,
> now you can go ahead and configure a static peer label; the following
> will assign the label "system_u:object_r:foo_peer_t:s0" to all
> IPv4 traffic coming in on eth0:
>
> # netlabelctl unlbl add interface:eth0 address:0.0.0.0/0 \
> label:system_u:object_r:foo_peer_t:s0
>
> At this point everything should be up and running, if not let us know :)
>
> Good luck!
>
> --
> paul moore
> linux @ hp
>
14 years, 2 months
- 1
- 0