Re: yum install policy-sources
by Tom London
Yeah, its not called that anymore if you are downloading from the
development tree.
You want 'selinux-policy-strict-sources' or
'selinux-policy-targeted-sources'.
tom
* /From/: Alexis Wagner <alexis wagner polymtl ca>
* /To/: "Fedora SELinux support list for users & developers."
<fedora-selinux-list redhat com>
* /Subject/: yum install policy-sources
* /Date/: Mon, 21 Jun 2004 14:19:45 -0400
------------------------------------------------------------------------
Hi,
I am trying to install policy-sources with yum and I get the following "error" :
# yum install policy-sources
Gathering header information file(s) from server(s)
Server: SELinux repository
Server: Fedora Core 2 - Development Tree
Finding updated packages
Downloading needed headers
Cannot find a package matching policy-sources
No actions to take
I am using this server for SELinux repository in yum.conf :
ftp://people.redhat.com/dwalsh/SELinux/Fedora
Is there another way to install the latest policy-sources ?
Thank you,
Alexis Wagner
19 years, 11 months
yum install policy-sources
by Alexis Wagner
Hi,
I am trying to install policy-sources with yum and I get the following "error" :
# yum install policy-sources
Gathering header information file(s) from server(s)
Server: SELinux repository
Server: Fedora Core 2 - Development Tree
Finding updated packages
Downloading needed headers
Cannot find a package matching policy-sources
No actions to take
I am using this server for SELinux repository in yum.conf :
ftp://people.redhat.com/dwalsh/SELinux/Fedora
Is there another way to install the latest policy-sources ?
Thank you,
Alexis Wagner
19 years, 11 months
update report....(>1000 updates and still ticking!)
by Tom London
I just completed 'eating' over 1000 updates from the development tree on
my 'bleeding edge' SELinux/strict/enforcing system. Updates included new
SELinux packages, new kernel,
new gnome/kde, ... just about new everything.
I detected NO significant SELinux installation issues!!!! This is quite
impressive (I'm sure it
is the result of much hard work). No packages failed to install, and I
as far a I could detect,
most packages are labeling correctly. In particular, the dev/MAKEDEV
packages appear
fixed (no problems in /dev or /udev), the kernel goes in smoothly
(/lib/modules/{build,kernel}
labeled properly), etc. etc. etc.
So far, I've detected only 3 'nits': the mozilla socket issue referred
in
http://www.redhat.com/archives/fedora-selinux-list/2004-June/msg00235.html,
a labeling issue for the mozilla plugin for users of j2sdk,
and 'gaim' no longer working properly (fails both in enforcing and
permissive mode,
so I suspect its not SELinux related).
Credit (and a tip of the hat) to the team!
tom
19 years, 11 months
slow to internet response
by david smethurst
hi all
having a problem with the response time in core2
this machine is dual boot and the response time is not the same in the
other os, therefore it must be in the se side of the linux as it wasnt
there before i installed core2
i did a fresh install
what happens is that there is at least a five to ten second gap between
the actual response on the router when any html site is selected
once it has found that site, ie web mail it changes the pages to the
respective request at normal speed changes
but that lag is on all new page requests and other core1, windows
machines on the same network dont have it
i am the only one so far to be using core2
please if you reply you will have to be very informative as to where to
find the things that you ask me to forward to you as i am very new to
linux, but happily learning everyday
thanks
david
19 years, 11 months
mounting ntfs volume
by david smethurst
hi all
what commands do i need to put into, i think fstab to mount a ntfs
volume and have read rights at user?
umask=0222 doesnt give it to me
thanks
david
19 years, 11 months
support for gigabit architecture
by Rajiv
Dear All,
Does fedora kernel support gigabit architecture. I would like to implement a 128-node clustering that is driven by 10-Gigabit switch.
Kindly give your suggestions on what swich, and what network card to use in the market.
Regards,
Rajiv
19 years, 11 months
C2 or B1
by Lawrence Bowie
At this point SELinux does not have official "Orange Book"
classification, right?
Thanks,
LDB
19 years, 11 months
Re: Where should an RPM install .te/.fc files?
by Jeff Johnson
Russell Coker wrote:
>---------- Forwarded Message ----------
>
>Subject: Re: Where should an RPM install .te/.fc files?
>Date: Thu, 17 Jun 2004 02:48
>From: "mike(a)flyn.org" <mike(a)flyn.org>
>To: fedora-selinux-list(a)redhat.com
>
>
>
>>>I maintain an RPM that installs .te and .fc files. In the past,
>>>contributing to the system's SELinux policy could be done by installing
>>>files in /etc/security/selinux/src/policy (I'm not sure this is right
>>>to begin with):
>>>
>>>%policy
>>>%{_sysconfdir}/security/selinux/src/policy/macros/pam_mount_macros.te
>>>
>>>
As noted, the path for installing *.fc and *.te files has changed.
Also, the %policy marker to include an absolute path in both the
metadata header
as well as as a file in the payload is not necessary. The original goal
was to have
rpm attempt "make reload" as well as setting file contexts, but there
are too
many unsolved problems trying to install policy piece wise to attempt.
>>>However, now policies may be in /etc/selinux/strict/src/policy/ or /
>>>etc/selinux/targeted/src/policy/. It is also possible that only one of
>>>these directories exists.
>>>
rpm will create directories in order to install files, so you need not
worry about
whether the directores exist. That is pure mechanism however, the
comments below
apply to the intent, rather than the mechanics, of installing *.te and
*.fc files.
>>>
>>>
>>I don't think that your macros file fits in with the targetted policy, and
>>I think that the general aims of the targetted policy don't involve that
>>sort of thing (but this hasn't been considered much so far).
>>
>>It's probably best to install the files under only the strict directory.
>>
>>It is also possible that only one of those directories exists.
>>
>>
>
>Installing exclusively under the strict policy make sense. The things I am
>explicitly allowing should probably already be allowed by the targeted
>policy. However, what about the case where a user does not have the strict
>policy installed? In this case my RPM will install its policy files to an
>otherwise empty policy source tree. This may result in directories like
>/etc/selinux/strict being orphans -- not owned by any RPM. Should this be
>avoided somehow?
>
>
Even if rpm creates "orphan" directories on the path needed for
installing a file,
the file context will still be set according to the currently configured
regexes.
That still isn't quite correct behavior, as "orphan" directories under
not under rpm control,
so any tools based on paths from an rpmdb will fail to change the
"orphan" directory
paths.
The best way (imho) to add 3rd party *.te and *.fc files to either the
targeted or strict trees
and avoid "orphan" directories is to add a file dependency on the parent
directory.
E.g., add
Requires: /etc/selinux/targeted/src/pollicy
if installing a file into that directory. That will avoid any "orphan"
directory problems
by forcing the package that owns the directory to be installed first.
Note that
any dependency on the package that "owns" the directory is sufficient,
use a package rather than a file dependency if you wish.
There is still the problem of how and when "make reload" is to be done
for the tree
when there are aadditional *.te and *.fc files being added. Probably the
best answer for
right now is to attempt the same operation in %post that is attempted by the
selinux-policy-{targeted,strict} package itself.
There is the erasure reload case that needs to be handled in %postun as
well.
Make sure you disambiguate erasure from upgrade by testing $1 in the
%postun script.
Here's what ypbind does, every package with a %preun and/or %postun has
examples:
if [ "$1" -ge 1 ]; then
/sbin/service ypbind condrestart > /dev/null 2>&1
fi
exit 0
The $1 argument is the number of instances of the pkg that will be
installed after the script is run, $1 == 0 is the pure erasure case, >= 1 is
the package upgrade case.
73 de Jeff
19 years, 11 months
xauth changes XAUTHORITY in su (was Re: up2date/seaudit/... not working (EXPLAINED))
by Tom London
Nalin,
Stephen Smalley's fix (move line in /etc/pam.d/su) fixed much of the
problem,
but running 'xauth' in another window still changes the setting of
XAUTHORITY
in the root shell that su spawns....
So, without xauth running, XAUTHORITY gets set to /root/.xauthABCD;
with xauth running, XAUTHORITY is unmodified (i.e., its value is
/home/USER/.Xauthority).
tom
[I didn't report that prior to the fix, 'su' was taking 20 seconds to
complete after entering
the correct password. This delay is now gone.]
------------------------------------------------------------------------
* /From/: Nalin Dahyabhai <nalin redhat com>
* /To/: fedora-selinux-list redhat com
* /Subject/: Re: up2date/seaudit/... not working (EXPLAINED)
* /Date/: Fri, 18 Jun 2004 16:28:15 -0400
------------------------------------------------------------------------
On Fri, Jun 18, 2004 at 12:00:44PM -0700, Tom London wrote:
> Running off of the development tree, I couldn't get graphical apps (like
> up2date, seaudit, ...) working when su'ed as root. All of this works
> fine on a 'stock FC2' machine (running off
> of the base and released-updates trees).
>
> The problem seems to be that the latest packages cause 'su' to change
> the settings of XAUTHORITY environment variable from
> 'XAUTHORITY=/home/USER/.Xauthority' to
> 'XAUTHORITY=/root/.xauthABCD' (ABCD the usual 'uniqueness' stuff).
>
> If you manually reset XAUTHORITY back to '/home/USER/.Xauthority', the
> apps work
> again.
>
> Here's a bit of added strangeness: if you start 'xauth' in another user
> window and then
> try 'su -l', XAUTHORITY is not changed in the root shell. No AVCs against
> /root/.authABCD either....
>
> [On the 'stock FC2' machine, XAUTHORITY is not modified by su.]
>
> I've bugzilla'ed this
> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126300)
> against coreutils, but I'm not sure that is the right place (e.g.,
> pam?). (All my systems
> run with SELinux enabled, so I can only assume this is occurring on
> SELinux-disabled
> systems as well.)
>
> Can someone explain why 'su' would be changing XAUTHORITY ?
The pam_xauth module reads the cookie for the current display for the
invoking user and creates a temporary cookie file containing just that
cookie for the target user.
While this isn't always necessary, if the invoking user's $XAUTHORITY is
in an NFS-mounted directory coming from a server which uses
root-squashing (and $XAUTHORITY is usually set to ~/.Xauthority, so it
happens), it becomes necessary because $XAUTHORITY would otherwise be
inaccessible.
If for some reason pam_xauth isn't able to do what it attempts to do, it
leaves the XAUTHORITY environment variable unchanged, so the behavior
you were seeing before was probably a bug of some kind.
I'm not sure how running another copy of 'xauth' would affect this,
really. xauth locks files when it opens them, but that should cause
'su' to just sit there until the copy of xauth which it started fails,
and you didn't mention any such delay.
Nalin
19 years, 11 months