more ptal_t (strict)
by Tom London
Running strict/enforcing, latest rawhide.
Previous suggested mods to cups.te for ptal-photod are insufficient.
The following appears needed to allow gimp to connect up to the scanner;
--- cups.te.save 2005-05-28 09:56:03.000000000 -0700
+++ cups.te 2005-05-29 11:30:10.000000000 -0700
@@ -150,6 +150,11 @@
allow ptal_t self:capability { chown sys_rawio };
allow ptal_t self:{ unix_dgram_socket unix_stream_socket }
create_socket_perms; allow ptal_t self:unix_stream_socket { listen
accept };
+can_network_tcp(ptal_t, self)
+allow ptal_t port_t:tcp_socket name_bind;
+allow userdomain ptal_t:unix_stream_socket connectto;
+allow userdomain ptal_var_run_t:sock_file write;
+allow userdomain ptal_var_run_t:dir search;
allow ptal_t self:fifo_file rw_file_perms;
allow ptal_t device_t:dir read;
allow ptal_t printer_device_t:chr_file rw_file_perms;
With these changes, gimp can acquire scanned image.
A few comments: ptal-photod seems to only use 127.0.0.1 for tcp
networking, and the allow for search on ptal_var_run_t:dir required
'enableaudit' to find. Is there an easier/better way to express this?
Sorry for the incomplete update last time....
tom
--
Tom London
18 years, 11 months
[ PATCH ]: evolution/thunderbird/gconf/orbit/other stuff - comments?
by Ivan Gyurdiev
Features:
- policy for evolution
- policy for thunderbird
- policy for generic mail client that they derive from
- policy for gconf
- common gnome macros (mozilla, evolution, thunderbird, gift, games,
gconf) use those
- macro for secure storage at .gnome(2)_private
- attempt at per role fonts
- per application labeled orbit sockets
- per application labeled ice sockets ( this is rather broken right
now )
- begin structuring things to confine bonobo in the future
- introduce untrusted type, but don't do anything with it yet
- restricted home_domain macro set to allow specifying transition class
in /home.
Default is now { dir } only, which is more restrictive than before.
- rework gift networking rules
- start writing ethereal policy ( not finished )
- bugfixes
I believe this is against selinux-policy-strict-sources-1.23.17-2
Issues:
(see my other message (nsa-list) - file_type_auto_trans
is not sufficient)
- need to patch libfontconfig to create font cache with proper type
- need to patch libgnome to create .gnome2 .gnome2_private,
and .gnome2/share/*fonts*
with correct type
- need to patch ORBit to create /tmp/orbit-* with correct type
- need to patch libICE to create /tmp/.ICE_unix with correct type
- need to give getfscreate/setfscreate privileges to all of those
(just like it's done for orbit_domain)
- need to patch evolution to create autosave composer files in
~/.evolution, not in $HOME
- need to fix everything relating to $HOME/.ICEauthority
- need to finish evolution exchange policy
- need to finish ethereal policy
- need to update boolean file
Status:
- can log in with almost no denials. There are the usual
strict policy bugs, there's some iceauth related denials,
but nothing too bad. Evolution works, but it
keeps popping up warning boxes every 15 seconds saying
it can't write its autosave files to $HOME - that needs
to be patched.
--
Ivan Gyurdiev <ivg2(a)cornell.edu>
Cornell University
18 years, 11 months
On building a smaller 'strict' policy.
by Valdis.Kletnieks＠vt.edu
OK, so I finally got fed up with having the 'strict' policy take up
4,821 or so *pages* of slab entries for avc_node, and decided to see how
much I could pare it down. Moving stuff I didn't actually have or use
from domains/program/foo.te into unused/foo.te more or less worked, and
only using up 2,230 pages of slab (a noticable difference on a 256M laptop).
Nits: In an effort to minimize the size even *more*, I tried nuking the
corresponding macros/program/foo_macros.te files, since much of the bulk of
the policy.conf is created by FOO_macros.te expanding a whole bunch of
USER_FOO_t for all user types (cdrecord chunks out some 100 per role, as
near as I can tell).
The resmgrd, kerberos, and ypbind entries in macros/programs end up getting
referenced in ways that fail gloriously when you try to build policy, so
obviously, wholesale skipping over macros the way the .tc files get skipped
over for unused .te isn't going to work. Fortunately, the four I had problems
with are defined in such a way that there's little real growth in the policy
because they're wrapped in a "ifdef(`foo.te')"
Would it be a Good Idea to be more agressive in wrapping the other FOO_macros.te
with such an ifdef? Or does this become a *total* non-issue with the soon-to-arrive
'loadable policy module' stuff?
For what it's worth:
[/etc/selinux/strict/src/policy]3 egrep -v '^#|^$' policy.conf | wc
28831 218148 1768137
A major savings. ;)
18 years, 11 months
FC3 Strict Policy
by Jeremy Utley
Hello Everyone!
I'm trying my first foray into experimenting with SELinux, and am
failing before I even get very far. I've installed Fedora Core 3 and
have enabled the SELinux strict policy. The only way I can log into
the system now is if I put the system into permissive mode. Here's
the denied errors I'm getting:
May 27 15:15:18 localhost kernel: audit(1117232118.583:0): avc:
denied { getattr } for pid=4380 exe=/sbin/unix_chkpwd
path=/var/run/winbindd dev=sda1 ino=1653914
scontext=system_u:system_r:system_chkpwd_t
tcontext=system_u:object_r:var_run_t tclass=dir
May 27 15:15:18 localhost kernel: audit(1117232118.586:0): avc: denied { read
write } for pid=4381 exe=/sbin/unix_chkpwd name=tty2 dev=tmpfs
ino=2025 scontext=system_u:system_r:system_chkpwd_t
tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file
May 27 15:15:18 localhost kernel: audit(1117232118.589:0): avc:
denied { getattr } for pid=4291 exe=/bin/login
path=/var/run/winbindd dev=sda1 ino=1653914
scontext=system_u:system_r:local_login_t
tcontext=system_u:object_r:var_run_t tclass=dir
May 27 15:15:18 localhost kernel: audit(1117232118.590:0): avc:
denied { getattr } for pid=4291 exe=/bin/login path=/root dev=sda1
ino=1864129 scontext=system_u:system_r:local_login_t
tcontext=root:object_r:staff_home_dir_t tclass=dir
The system is fully up to date via yum. I realize some problems can
be expected when using the strict policy as opposed to targeted - but
I can't believe the strict policy would ship in a configuration that
prevents logging into the system.
Anyone got any suggestions - I can't believe I'm the only person who's
faced this, but I did a lot of searching online and couldn't find
anything.
Jeremy
18 years, 11 months
ptal (hpoj) fixes ?
by Tom London
Running strict/enforcing, latest rawhide.
When hpoj/cups starts, I get:
May 25 07:52:07 fedora ptal-mlcd: SYSLOG at ExMgr.cpp:652,
dev=<mlc:usb:PSC_900_Series>, pid=2189, e=2, t=1117032727
ptal-mlcd successfully initialized.
May 25 07:52:07 fedora ptal-printd:
ptal-printd(mlc:usb:PSC_900_Series) successfully initialized using
/var/run/ptal-printd/mlc_usb_PSC_900_Series*.
May 25 07:52:09 fedora kernel: audit(1117032729.705:10): avc: denied
{ name_bind } for pid=2192 comm="ptal-photod" src=5703
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t
tclass=tcp_socket
May 25 07:52:09 fedora ptal-photod:
ptal-photod(mlc:usb:PSC_900_Series) successfully initialized,
listening on port 5703.
May 25 07:52:12 fedora kernel: audit(1117032732.982:11): avc: denied
{ write } for pid=2189 comm="ptal-mlcd" name=002 dev=usbfs ino=4435
scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t
tclass=file
May 25 07:52:13 fedora ptal-mlcd: SYSLOG at
/usr/src/build/533581-i386/BUILD/hpoj-0.91/mlcd/ExMgr.h:646,
dev=<mlc:usb:PSC_900_Series@/dev/usb/lp0>, pid=2189, e=5, t=1117032733
ptal-mlcd successfully activated, mode=1284.4.
So
allow ptal_t usbfs_t:file write;
appears needed.
For the name_bind avc, should ptal-photod be labeled ptal_t so we get
a transition from initrc_t to ptal_t?
tom
--
Tom London
18 years, 11 months
relabeling of /etc/sysconfig/network-scripts/ifcfg-* (targeted)
by Tom London
Running targeted/enforcing, latest rawhide.
Each time I boot, running 'restorecon -v -R /etc' produces:
restorecon reset /etc/sysconfig/network-scripts/ifcfg-eth1 context
system_u:object_r:etc_t->system_u:object_r:net_conf_t
restorecon reset /etc/sysconfig/network-scripts/ifcfg-eth0 context
system_u:object_r:etc_t->system_u:object_r:net_conf_t
restorecon reset /etc/sysconfig/networking/profiles/default/ifcfg-eth1
context system_u:object_r:net_conf_t->system_u:object_r:etc_t
restorecon reset /etc/sysconfig/networking/profiles/default/ifcfg-eth0
context system_u:object_r:net_conf_t->system_u:object_r:etc_t
Actually, after the restorecon, the labels are unchanged, that is, the
first 2 are still etc_t, not net_conf_t.
I'm not using NetworkManager, just the base stuff....
Nothing is broken, but I don't understand this....
tom
--
Tom London
18 years, 11 months
Multi-level security
by George J. Jahchan
Is there a way in SE Linux to set security levels to sources / targets and deny
access from a source to any target whose security level is higher than that of
the source?
18 years, 11 months
Re: Auditd & Strict Policy 1.19
by George J. Jahchan
Stephen,
Followed your instructions, adding 'audit write & audit_control' at the end of
the capability section in the policy/flask/access_vectors elicits the following
error message when making the policy:
... too many permissions to fit in an access vector.
It will accept any two of the three in the capability section of access_vectors,
at which time it complains as follows:
... 'permission [omitted permission from the above] is not defined for class
capability' ...
Bearing in mind that the machines are live production hosts, how do you
recommend we address this (from the available choices below)?
1) For a limited period of time (until FC4 is released), we can live with having
to switch to permissive mode in order to start the audit daemon, and revert back
to enforcing mode after it starts. The hosts are not taken down that often.
2) We can upgrade to FC4 strict policy, with no assurance that it will work or
not cause other problems.
3) We can upgrade to pre-release FC4, again with no assurance that it will work
or will not introduce new weaknesses.
Thank you for your help.
-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
Sent: Friday, May 20, 2005 3:09 PM
To: George J. Jahchan
Cc: Fedora SE Linux List
Subject: Re: Auditd & Strict Policy 1.19
On Fri, 2005-05-20 at 10:12 +0300, George J. Jahchan wrote:
> On a Bastilled FC3 latest kernel and with the strict SE Linux policy (1.19),
if
> not in permissive mode, the auditd daemon refuses to start with the following
> error messages in /var/log/messages:
>
> ... Unable to set audit pid, exiting.
> ... Error sending failure mode request (Operation not permitted).
>
> Once the daemon starts in permissive mode, it is not a problem to revert SE
> Linux back to enforcing mode, the daemon stays up (and performs as expected).
>
> Have started Fedora with audit=1 kernel option and enabled the noisy events in
> SE Linux (make enableaudit & make load in the strict policy source directory),
> auditd-related denials have all been explicitly allowed in our custom.te
policy
> under domains/misc. Auditd daemon still fails to start in enforcing mode, and
no
> selinux denials are generated when we try to start it.
>
> Using the above method, we have been able to get the system to boot in
enforcing
> mode and run all the programs & daemons we needed to run (with no selinux
> denials, except attempts to access shadow_t which is protected by an assertion
> in the strict policy), except for auditd.
>
> Any hints on how to resolve this issue?
With regard to the denial, I suspect it is due to recently introduced
(as of 2.6.11) new capability checks performed in the receive-side
kernel audit code, which unfortunately cannot generate audit messages
presently. This will hopefully be resolved as part of some ongoing
work. Hence, you likely need:
allow auditd_t self:capability { audit_write audit_control };
in policy/domains/program/auditd.te, and you likely need to add those
permission definitions to policy/flask/access_vectors at the end of the
class capability definition as the FC3 policy would not have included
them.
BTW, when using strict policy, it is always advisable to use the latest
rawhide policy (in this case, FC4/devel) in order to pick up the latest
fixes. Also, there has been a lot of work done in FC4/devel on the
kernel audit framework, auditd, auditctl, and other userspace support
for auditing in order to prepare it for CAPP evaluation, so if you truly
want to use auditing in general (beyond just the SELinux auditing), you
may want to move to FC4.
--
Stephen Smalley
National Security Agency
18 years, 11 months
ainit (xdm_t) wants to write /etc/alsa/pcm/dmix.conf (etc_t) ...
by Tom London
Running strict/enforcing, latest rawhide.
Get the following when logging in:
May 21 13:30:16 fedora gdm(pam_unix)[2946]: session opened for user
tbl by (uid=0)
May 21 13:30:16 fedora kernel: audit(1116707416.740:0): avc: denied
{ write } for name=dmix.conf dev=hda2 ino=4523476
scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t
tclass=file
May 21 13:30:16 fedora ainit: Failed to open file /etc/alsa/pcm/dmix.conf
May 21 13:30:16 fedora ainit: Error: Permission denied
The file in questions is /etc/alsa/pcm/dmix.conf.
/etc/alsa/ainit.conf has:
#
# overwrite target files, if exists
#
overwrite = yes
#
# first config file - for dmix plugin
#
template_0 = /etc/alsa/pcm/dmix.template
target_0 = /etc/alsa/pcm/dmix.conf
target_root_file_0 = yes
This seems less than perfect to me....
Should dmix.conf (and dsnoop.conf) be someplace else? Labeled as
xdm_rw_etc_t? (I don't know who else needs to read these files....)
tom
--
Tom London
18 years, 11 months
/proc {getattr} failures
by James Z. Li
targeted policy on FC3
/var/log/messages show lots of avcs:
May 22 20:54:42 bengal kernel: audit(1116809682.160:0): avc: denied
{ getattr } for pid=2733 exe=/bin/ps path=/proc/1 dev=proc ino=65538
scontext=user_u:system_r:httpd_sys_script_t
tcontext=user_u:system_r:unconfined_t tclass=dir
...
May 22 20:54:42 bengal kernel: audit(1116809682.171:0): avc: denied
{ getattr } for pid=2733 exe=/bin/ps path=/proc/2660 dev=proc
ino=174325762 scontext=user_u:system_r:httpd_sys_script_t
tcontext=root:system_r:unconfined_t tclass=dir
'audit2allow' generates this rule in local.te
allow httpd_sys_script_t unconfined_t:dir { getattr };
'make load' shows the assertion error message
Assertion on line 17328 violated by allow httpd_sys_script_t
unconfined_t:dir { getattr };
make: *** [/etc/selinux/targeted/policy/policy.18] Error 1
Then I learned that /proc, /selinux, and /sys do not have persistent
labels. What should
I do to solve this problem? Remove that assertion check?
Btw, anyone has a policy file for Gallery (gallery.sourceforge.net) with httpd?
Thanks a lot!
18 years, 11 months