tmpfs /dev
by Russell Coker
I have got a working system with tmpfs /dev and with udev in the initrd. I
modified /sbin/init to run the following script immediately after loading the
policy:
#!/bin/sh
. /etc/selinux/config
/sbin/setfiles-mine /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts /dev
Naturally we need to change the location of setfiles to /sbin from /usr/sbin
if this is the solution we choose as this script will run before any file
systems are mounted.
Below is the policy I added. I had already changed the type declarations to
use the dev_filesystem attribute for everything that may occur under /dev
(patch sent to the main SE Linux list). I have setfiles being run as
kernel_t because I feel that running setfiles as kernel_t is better than
granting setfiles_t more access than is otherwise required. This means that
I have to grant kernel_t access to relabel the device nodes, no big deal IMHO
as kernel_t generally has ultimate access anyway.
I relabeled /sbin/MAKEDEV as udev_exec_t so that it runs as udev_t when run
from /sbin/start_udev and can do the things that it wants to do. This is a
minor hack. Maybe it would be better to label /sbin/start_udev as
udev_exec_t? That would remove the need to allow initrc_t to create
sym-links under /dev.
avc: denied { getattr } for pid=1641 exe=/sbin/lvm.static
path=/sbin/MAKEDEV dev=dm-0 ino=196261 scontext=system_u:system_r:lvm_t
tcontext=system_u:object_r:udev_exec_t tclass=file
Why does lvm.static want to stat /sbin/MAKEDEV? Seems strange to me.
Below is the policy I wrote to allow tmpfs /dev and udev in initrd. I haven't
split it into all the relevant .te files because it's still an experiment at
this stage. After some discussion I'll produce a release version.
# for tmpfs /dev
allow dev_filesystem tmpfs_t:filesystem associate;
allow kernel_t tmpfs_t:chr_file rw_file_perms;
allow kernel_t tmpfs_t:{ dir file lnk_file chr_file blk_file } { getattr
relabel
from };
allow kernel_t device_t:{ dir lnk_file chr_file blk_file } relabelto;
allow kernel_t device_type:{ chr_file blk_file } relabelto;
allow kernel_t udev_tbl_t:file relabelto;
can_exec(kernel_t, { sbin_t setfiles_exec_t })
# for /dev/pts on tmpfs
allow mount_t tmpfs_t:dir mounton;
# for /sbin/MAKEDEV - why?
allow lvm_t udev_exec_t:file getattr;
# allow /sbin/start_udev to run ln
allow initrc_t device_t:lnk_file create_lnk_perms;
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
19 years, 7 months
Will FC3 grub DTRT wrt installation on software RAID-1 boot arrays
by Yusuf Goolamabbas
Hi, I haven't tested FC3test as yet and wanted to ask if grub in FC3
would do the right thing when installing on a software raid-1 boot array
(ie, that it would write to the MBR on both disks) so if there was a
disk failure, the machine would still come up. Currently in FC1/FC2, if
you install on software raid-1 array and then remove the first disk, the
system won't boot up since there is no boot information on the MBR of
the 2nd disk. lilo would do the right thing but since that's being
deprecated. I don't know if Grub is capable of this task
An engineer from Dell has provided a document which gives a workaround
for this
http://lists.us.dell.com/pipermail/linux-poweredge/2003-July/014331.html
Regards, Yusuf
19 years, 7 months
Plans to include tools to make FC3 more user-friendly in terms of RPM?
by Kyrre Ness Sjobak
I'm just wondering: Why was the "rpm-dubbleclick-to-install" feature
removed from FC2? It worked quite well in FC1 and RH9, and made
installing RPM's much easyer for newbies. Will this tool (or something
similar) be included into FC3, and if not, why? If there is anything i
can do to help, please tell.
I am also wondering if there is any plans to include a (one of the)
grapichal frontends to yum.
Kyrre Ness Sjøbæk
19 years, 7 months
rawhide report: 20040910 changes
by Build System
Updated Packages:
anaconda-10.0.2-3
-----------------
* Thu Sep 09 2004 Anaconda team <bugzilla(a)redhat.com>
- built new version from CVS
* Thu Jun 03 2004 Jeremy Katz <katzj(a)redhat.com>
- require system-logos and anaconda-help, obsolete anaconda-images
* Fri Apr 30 2004 Jeremy Katz <katzj(a)redhat.com>
- Update description, remove prereq on stuff that was only needed
for reconfig mode
kudzu-1.1.89-1
--------------
* Thu Sep 09 2004 Bill Nottingham <notting(a)redhat.com> - 1.1.89-1
- fix searching when it returns descriptionless keys
rpmdb-fedora-2.91-0.20040910
----------------------------
19 years, 7 months
FC3: Gnome 2.8 system tools
by Arangel Angov
I think that this is the right place to disscuss this...
While translating gnome 2.8 I noticed that gnome-system-tools is very
similiar with all of the redhat sys-tools. How is this going to be
resolved in FC3? Will there be no gnome-system-tools in the gnome
edition that comes with FC3? Cause it wouldn't be nice if we have them
both (personally, I wouldn't like the rh tools to go) and I just doubt
that the fedora developers are going to get rid of the rh tools.
Arangel
19 years, 7 months
vsftpd (GPL) and openssl?
by Warren Togami
I just noticed this in cvs-commits. Another new instance of GPL linking
with openssl. Problematic?
Even if the vsftpd authors wont sue us for any possible GPL violation,
does this possibly open a weak link in vsftpd's supposedly "very
secure"ness? Even if ssl is disabled by default in our config? Please
be sure...
Warren Togami
wtogami(a)redhat.com
-------- Original Message --------
Subject: rpms/vsftpd vsftpd-2.0.1-build_ssl.patch,NONE,1.1
vsftpd.spec,1.44,1.45
Date: Wed, 8 Sep 2004 03:55:46 -0400
From: Radek Vokal <rvokal(a)redhat.com>
Reply-To: cvs-commits-list(a)redhat.com
Organization: Red Hat Inc. Internal News
Newsgroups: rhat.general.cvs.cvs-rhlinux
Update of /cvs/pkgs/rpms/vsftpd
In directory cvs.devel.redhat.com:/tmp/cvs-serv32111
Modified Files:
vsftpd.spec
Added Files:
vsftpd-2.0.1-build_ssl.patch
Log Message:
- added patch by Jan Kratochvil for SSL support
vsftpd-2.0.1-build_ssl.patch:
builddefs.h | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- NEW FILE vsftpd-2.0.1-build_ssl.patch ---
--- vsftpd-2.0.1/builddefs.h-orig 2004-07-02 16:36:59.000000000 +0200
+++ vsftpd-2.0.1/builddefs.h 2004-08-17 13:40:42.834402983 +0200
@@ -3,7 +3,7 @@
#undef VSF_BUILD_TCPWRAPPERS
#define VSF_BUILD_PAM
-#undef VSF_BUILD_SSL
+#define VSF_BUILD_SSL
#endif /* VSF_BUILDDEFS_H */
Index: vsftpd.spec
===================================================================
RCS file: /cvs/pkgs/rpms/vsftpd/vsftpd.spec,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- vsftpd.spec 27 Aug 2004 10:56:11 -0000 1.44
+++ vsftpd.spec 8 Sep 2004 07:55:44 -0000 1.45
@@ -3,7 +3,7 @@
Summary: vsftpd - Very Secure Ftp Daemon
Name: vsftpd
Version: 2.0.1
-Release: 2
+Release: 3
License: GPL
Group: System Environment/Daemons
URL: http://vsftpd.beasts.org/
@@ -19,10 +19,17 @@
Patch4: vsftpd-1.5.1-libs.patch
Patch5: vsftpd-2.0.1-signal.patch
Patch6: vsftpd-1.2.1-conffile.patch
+Patch7: vsftpd-2.0.1-build_ssl.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
%if %{tcp_wrappers}
BuildPrereq: tcp_wrappers
%endif
+BuildRequires: pam-devel
+Requires: pam
+BuildRequires: libcap-devel
+Requires: libcap
+BuildRequires: openssl-devel
+Requires: openssl
# for -fpie
BuildPrereq: gcc > gcc-3.2.3-13, binutils > binutils-2.14.90.0.4-24,
glibc-devel >= 2.3.2-45
Requires: logrotate
@@ -45,6 +52,7 @@
cp %{SOURCE1} .
%patch5 -p1 -b .signal
%patch6 -p1
+%patch7 -p1 -b .build_ssl
%build
%ifarch s390x
@@ -52,7 +60,7 @@
%else
make CFLAGS="$RPM_OPT_FLAGS -fpie -pipe" \
%endif
- LINK="-pie" \
+ LINK="-pie -lssl" \
%{?_smp_mflags}
%install
@@ -102,10 +110,13 @@
/var/ftp
%changelog
-* Fri Aug 27 2004 Radek Vokal <rvokal(a)redhat.com>
+* Wed Sep 08 2004 Jan Kratochvil <project-vsftpd(a)jankratochvil.net>
+- update for 2.0.1 for SSL
+
+* Fri Aug 27 2004 Radek Vokal <rvokal(a)redhat.com> 2.0.1-2
- vsftpd.conf file changed, default IPv6 support
-* Fri Aug 20 2004 Radek Vokal <rvokal(a)redhat.com>
+* Fri Aug 20 2004 Radek Vokal <rvokal(a)redhat.com> 2.0.1-1
- tcp_wrapper patch updated, signal patch updated
- upgrade to 2.0.1, fixes several bugs, RHEL and FC builds
19 years, 7 months