selinux May 2005

selinux@lists.fedoraproject.org

47 participants
63 discussions

more ptal_t (strict)
by Tom London 30 May '05

30 May '05

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

3 6

[ PATCH ]: evolution/thunderbird/gconf/orbit/other stuff - comments?
by Ivan Gyurdiev 29 May '05

29 May '05

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

1 0

On building a smaller 'strict' policy.
by Valdis.Kletnieks＠vt.edu 29 May '05

29 May '05

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. ;)

1 0

FC3 Strict Policy
by Jeremy Utley 27 May '05

27 May '05

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

2 1

ptal (hpoj) fixes ?
by Tom London 26 May '05

26 May '05

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

2 1

relabeling of /etc/sysconfig/network-scripts/ifcfg-* (targeted)
by Tom London 26 May '05

26 May '05

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

2 1

Multi-level security
by George J. Jahchan 26 May '05

26 May '05

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?

2 1

Re: Auditd & Strict Policy 1.19
by George J. Jahchan 26 May '05

26 May '05

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

2 3

ainit (xdm_t) wants to write /etc/alsa/pcm/dmix.conf (etc_t) ...
by Tom London 25 May '05

25 May '05

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

2 5

/proc {getattr} failures
by James Z. Li 25 May '05

25 May '05

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!

5 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux May 2005