subscribe
by Ed Franks
FYI:
I found this list email address in the new O'Reilly book:
"SELINUX NSA's Open Source Security Enhanced Linux" by Bill McCarty
... which just hit the street. On pg 198, it posts this email address
as a place to review postings. You may expect many more hits due to
this new published work.
I have been a follower of SELinux for over 3 years: since attending
Stephen Smalley's presentation at USENIX June 2001 in Boston. I have
explored quite a bit with SELinux, LIDS, and other implementations of
the Linux kernel capabilities features.
regards,
ed
--
Ed Franks Contracted to:
SysAdmin - Solaris/Linux/Security o CIO Office
UNISYS Federal Systems _.<\-' Air Force Research Lab
Albuquerque, New Mexico ...(_)/_(_) Kirtland AFB
19 years, 4 months
chkpwd_macros.te
by Tom London
running rawhide/strict,
I get the following about once or twice a day:
Nov 10 06:49:17 fedora kernel: audit(1100098157.523:0): avc: denied
{ search } for pid=27040 exe=/sbin/unix_chkpwd name=run dev=hda2
ino=4456484 scontext=user_u:user_r:user_chkpwd_t
tcontext=system_u:object_r:var_run_t tclass=dir
Nov 10 06:49:17 fedora kernel: audit(1100098157.523:0): avc: denied
{ search } for pid=27040 exe=/sbin/unix_chkpwd name=nscd dev=hda2
ino=4556982 scontext=user_u:user_r:user_chkpwd_t
tcontext=system_u:object_r:nscd_var_run_t tclass=dir
Suggest the following:
--- SAVE/chkpwd_macros.te 2004-11-10 07:37:22.098409600 -0800
+++ ./chkpwd_macros.te 2004-11-10 07:38:32.387484758 -0800
@@ -67,6 +67,8 @@
# for nscd
dontaudit $1_chkpwd_t var_t:dir search;
+dontaudit $1_chkpwd_t var_run_t:dir search;
+dontaudit $1_chkpwd_t nscd_var_run_t:dir search;
dontaudit $1_chkpwd_t fs_t:filesystem getattr;
')
tom
--
Tom London
19 years, 4 months
Re: selinux and /etc/passwd
by Stephen Smalley
On Tue, 2004-11-09 at 00:23, Sergiu Giurgiu wrote:
> hi,
> I've just installed FC3 tonight (clean install) and ... I've came across
> a small problem.
> Users cannot be created. I hev created a user at the first-boot wizard,
> I have tried to use the graphical tool, and ... at the console I tried
> to use useradd. The wizard didn't say anything (like everything was ok),
> the user/group manager graphical tool remain blocked when I pressed OK
> to add a new user, but useradd said that it cannot alter /etc/passwd (I
> don't recall the exact message). As a result, I couldn't add a new user.
> To start eventually working, I have disabled selinux and rebooted.
> everthing works fine now.
> Given that I'm not quite knowledgeable about selinux (why is it there
> and what is it doing), and this machine functions as a
> workstation/desktop machine, I can say that I'm ok with this solution.
> However I would like to know what was happening. Is it a bug (didn't
> found reports about this)? It's a feature? Can it be fixed? If so, how?
> The filesystem installed is reiserfs (does it matter?).
> Thank you.
What does 'audit2allow -v -i /var/log/messages' show? reiserfs doesn't
yet support individual file labeling for SELinux, so all files in it are
mapped to a single security type, but I would have expected you to be
able to access it under the targeted policy just fine.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
19 years, 4 months
Re: first encounters with SELINUX, with some suggestions
by Stephen Smalley
On Tue, 2004-11-09 at 07:12, Thomas Vander Stichele wrote:
> The latter has a paragraph about where policy is stored, and mentions
> Makefiles and other stuff in /etc/selinux. None of this is present on
> my FC3 system, so I'm assuming here that Red Hat has changed some things
> from the default SELinux which obliviate this step, but I have way of
> finding out how. Am I missing something ? Maybe there's a package I
> need to install ?
FC3 places the policy under /etc/selinux/targeted (or strict, if using
that policy). By default, only the compiled policy
(selinux-policy-targeted) is installed, I think. You need to install
selinux-policy-targeted-sources for the policy sources. The policy
sources and Makefile are placed under /etc/selinux/targeted/src/policy.
> The former howto tells me I can run
> /sbin/fixfiles relabel /home/thomas/www
>
> but that command just gives me this:
> Usage: /sbin/fixfiles {-R rpmpackage[,rpmpackage...] [-l logfile ] [-o
> outputfile ] |check|restore|[-F] relabel}
>
> It would seem to me that what I issued was correct, both from the howto
> as well as the usage output. Clearly I'm missing something else here.
fixfiles doesn't take a list of directories, AFAIK, nor does the usage
message say that it does. It is just a script front-end by RedHat for
the setfiles program. setfiles was the original program, used to label
entire filesystems for an initial install of SELinux, although it can be
applied to a subtree.
> So I tried this:
> restorecon -v -R /home/thomas/www
>
> and that did something. How do these two tools differ ? Why does the
> first not work as advertised.
setfiles - The original upstream program. Relabels or checks entire
filesystems or at least a subtree starting from the specified
directories. Requires explicit specification of a file_contexts
configuration and of the list of directories to traverse.
fixfiles - script front-end by RedHat for setfiles. Doesn't require (or
even permit) specification of a file_contexts configuration or a list of
directories to traverse; has some additional features like being able to
selectively relabel all files in a given package.
restorecon - variant of setfiles program by RedHat. Doesn't require or
permit specification of a file_contexts configuration; does require
specification of paths to relabel; only traverses directories
recursively if -R is specified. This is more like a chown/chmod-style
program, except you don't have to specify the context itself, as that is
obtained from the file_contexts configuration based on the pathname.
Over time, restorecon has been getting more and more like setfiles (e.g.
via -R option); it just presents a different default interface to the
user. Should likely be merged with setfiles in some manner.
chcon - chown/chmod equivalent for security contexts. You specify the
context and the individual files, can also recurse via -R.
> Using ls -alz /home/thomas I seem to get the impression this security
> context has been adopted. Still, apache refuses to see the directory.
>From the initial denial, it looked like apache couldn't even search the
top-level home directory ("thomas") because it lacked the proper
security context (should have user_home_dir_t, not default_t).
restorecon -R /home/thomas.
> So I read some more of the howto. There's a binary called audit2allow
> that could help me generate rules. So I run it, restart apache a few
> times, but the binary doesn't print anything, not even with -v. Maybe
> I'm using it wrong, but there's no way of finding out if I am.
audit2allow -d (to read audit from dmesg output) or audit2allow -i
/var/log/messages (to read from the messages file). Otherwise, it
defaults to acting as a filter, reading from stdin. Possibly not the
best choice of interface.
> Maybe it would be a good idea to write a simple "getting started" guide
> explaining how to do two or three common tasks (I'd say "serving web
> pages from a nonstandard directory" would be one of them), making sure
> that EVERY STEP works. Right now the howto contains things that do not
> work as advertised, and links to docs that reference stuff that is not
> present, without a mention close by where to get it.
I think Colin has/is working on such a guide. I agree that the existing
documentation is inadequate, and that part of the problem is that there
is too much reliance on documentation that predates the Fedora SELinux
integration and doesn't reflect changes made for it. Even FC2->FC3
introduced a lot of changes, so some documentation that was updated for
FC2 is now out of date.
> - A lot of developers I know, including a bunch at Red Hat, *turn off
> SELINUX entirely*. IMO, something that gets pushed at heavily as this
> should be dogfooded by the development team at Red Hat completely, so
> they encounter firsthand what it means and how to fix basic issues.
> Knowledge spreads through increasingly growing circles starting from the
> center. If all RH developers, who have "easy" access to the SELINUX
> people at Red Hat, were to use it, they'd have basic knowledge about it.
> When the next circle of developers - outside of redhat, but having links
> to inside - gets hit, they do the same. And so on.
>
> It looks to me like the first circle is already completely broken, hence
> halting the dissemination of information and increasing the annoyance
> level outside of Red Hat. It won't be long before sysadmins and users
> ignore the default and turn it off entirely.
Fair point, no argument here.
> - The documentation is not easy to find, out of date, and doesn't match
> the system. IMO, if FC3 gets released, the howto for something as basic
> as SELINUX should be uptodate and easy to find.
Yes, and either there shouldn't be so much reliance on pre-existing
documentation that predates Fedora SELinux integration or Fedora project
should be submitting patches to update that pre-existing documentation.
> I just want to get a good picture of where SELINUX is at and how to
> solve issues, so that I can try to fix stuff myself, and explain to
> other people. Otherwise I'll just have to turn off SELINUX myself, and
> recommend the same to others when questions are asked about it.
>
> Feel free to comment, both on the particular issue at hand as well as
> the general issue of entry barriers to selinux.
Thanks for the feedback, and sorry for your troubles.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
19 years, 4 months
privoxy.te
by Tom London
Running strict/enforcing off of latest rawhide
(selinux-policy-strict-1.18.2-2):
privoxy generates:
Nov 7 13:44:10 fedora kernel: audit(1099863850.432:0): avc: denied
{ connect } for pid=14703 exe=/usr/sbin/privoxy
scontext=system_u:system_r:privoxy_t
tcontext=system_u:system_r:privoxy_t tclass=udp_socket
Nov 7 13:44:10 fedora kernel: audit(1099863850.469:0): avc: denied
{ connect } for pid=14703 exe=/usr/sbin/privoxy
scontext=system_u:system_r:privoxy_t
tcontext=system_u:system_r:privoxy_t tclass=tcp_socket
This patch seems to fix it:
--- SAVE/privoxy.te 2004-11-07 18:00:09.433732712 -0800
+++ ./privoxy.te 2004-11-07 18:00:40.419276794 -0800
@@ -18,6 +18,7 @@
# Use the network.
can_network(privoxy_t)
allow privoxy_t port_t:{ tcp_socket udp_socket } name_bind;
+allow privoxy_t self:{ tcp_socket udp_socket } connect;
allow privoxy_t etc_t:file { getattr read };
allow privoxy_t self:capability { setgid setuid };
allow privoxy_t self:unix_stream_socket create_socket_perms ;
tom
--
Tom London
19 years, 4 months
setools in Fedora
by Yuichi Nakamura
I tried to use setools in FedoraCore3-test3.
I installed from rpm in Fedora project server.
setools-1.4.1-5, setools-gui-1.4.1-5
gui tools(apol,sepcut) are very slow before window is shown.
In FedoraCore2, it was slow, too.
When I used setools in FedoraCore1, setool is fast enough in the same machine.
---
Yuichi Nakamura
Japan SELinux Users Group(JSELUG)
http://www.selinux.gr.jp/
Hitachi Software
http://www.selinux.hitachi-sk.co.jp/en
The George Washington University
19 years, 4 months
PT_GNU_STACK, ld.so.cache and java
by Tom London
The 'legacy' binary problem seems to hit
the java VMs I've installed and tested
under strict/enforcing (java-1-4.2 and java-1.5.0).
'execstack -c' doesn't fix this.
Any pointers to 'Fedora compiled' versions
or workarounds? ('gij' doesn't seem
to cut it.)
thanks,
tom
--
Tom London
19 years, 5 months
Truncated log entries
by Barry Roomberg
I'm running Fedora Core 2 Kernel: 2.6.5-1.358
I'm logging activity in a directory (thanks Stephen).
I occasionally get what look like to be truncated log entries such as:
Oct 27 11:24:21 mstoppel1 kernel: audit(1098890661.257:8894633):
avc: granted { read } for pid=17834 exed=500 fsuid=500 egid=500
sgid=500 fsgid=500
"exed=500" ???
also:
Oct 27 11:26:47 mstoppel1 kernel: =500 fsgid=500
Any idea why? They are rare and interspersed with good entries.
19 years, 5 months