Please accept my apology for how long this is, in the end it is
effectively a feature request (or perhaps a packing ''issue'')... it
just takes a while to get there.
After installing a typical RHEL/Fedora server a non privileged user has
access to read all sorts of files that, while not terribly dangerous,
they have no need to read and could, under some not at all extraordinary
circumstances, disclose some more sensitive data. I know in a good part
of the server world user's simply are not a valid concern. However, I
would be surprised if any Unix based shop didn't have at least one
server where users could ssh in and put files down.
For example a standard user can read just about everything
in /etc/samba, like the smbusers file which maps unix users to smb
users. The big picture in this file is that it maps root to
Administrator. This is something that we expect, but disclosing it
seems in error. A security minded admin may change the mapping, but,
since there is never a case where a non uid 0 process would need to read
the file (samba runs as root), the permissions may never be tightened
There is also the /etc/samba/smb.conf file which is world readable. A
wealth of information that should never be given to users is in this
file, as an admin I would expect this file to be not world readable by
default. No one needs to read it but me, so I shouldn't share it with
How about /etc/httpd/* I have a personal hosting account at a server
farm where I can read everything in that directory. A quick check of
the /etc/httpd/conf/httpd.conf tells me the name of every site hosted on
this box. /home/37462614 doesn't tell me who this is, but a simple poke
about in apache tells me all sorts of things. Like in this user's home
they have a .ht_passwords file with customer access rights. A file that
I can cat if I want and compromise their privacy. A file I must be able
to cat because of the apache permissions. A file I would never have
found if I hadn't been able to read the httpd.conf file. The httpd.conf
file that as a non-root user, I never have a reason to read.
The /etc/yum files are also world readable, knowing who is and is not a
trusted software provider is just not something non-root users should
need to know.
The SNMP config file (/etc/snmp/snmpd.conf) is world readable by
default. Disclosing this information to a non-administrative user is
not a good idea. Supposing I enable SNMP writes. Giving any user
access to this file after SNMP writes are enabled is rather bad.
Chmoding it root only isn't listed in the documentation. Doesn't it
seem a little strange that this is not automatically handled by the RPM
on installation. Edits to the file will preserve the umask, and
therefore retained. The 99% use case for snmpd is to only allow
administrative users access to this file. The defaults apply to the 1%
case where something else is at work.
I wish to challenge this choice. Not just for SNMP but for every file
and directory in /etc/. I would love for a secure configuration by
default. seLinux is installed by default, the mandatory access control
there is excellent, but there is no reason to have to rely on it when
for 90% of the files in /etc/ a simple chmod will secure the files
I realize one of the first reactions will be to let seLinux take care of
it. SeLinux is great at this task, but it seems like pushing the burden
entirely into seLinux is hiding the oddity I am pointing out. Suppose I
had /etc/httpd/ recursively set to 2777 by default. This is obviously
bad, but due to seLinux enforcement the apache process would not be able
to modify /etc/httpd/ files, but wouldn't it make more sense to chmod
things differently in the RPM? I realize that write access and random
sticky bits are far greater than just a world read bit, but just because
you can do something with seLinux doesn't mean it is the best way to do
The list of random files in /etc/ could go on for a long while, but I
would ask that a part of the packaging process going forward would be to
evaluate the default permissions on all files packaged in /etc/ and
decide if any of the world bits should be set. Allowing anything on the
system to read files in /etc/ is not a good idea. I know seLinux, when
it is enforcing, prevents a lot of this disclosure, but users are
currently unconfined in the default RHEL5/Fedora9 and many admins (not
myself, but it is still a sizable group) turn off seLinux. In security
classes they stress having many lines of defense, setting good
permissions by default seems a great place to start, just a serious
outlay of work and a large bit of time.
I know confined users is coming, but there are times I must put seLinux
into Permissive mode. And confined users is not here yet. With the
complexity of confining users I would not be the slightest bit shocked
if it took a few more years to happen. Getting /etc/ locked down a bit
tighter will help demonstrate that RHEL/Fedora is not only secure with
seLinux running, but rather that seLinux is an extension of the security
focus you expect to see from an Enterprise Linux provider. That even in
non seLinux environments the system takes precautions about what data
should and should not be given to non-root users.
May I request that a step be added to the packaging process? A step
where the world read bits are evaluated for validity. Obviously
evaluating past packages is a ridiculous idea, but perhaps for the next
release of Fedora any packages that start coming in could have this
request attached to them.
Reminder: This Weekend
-------- Original Message --------
Subject: bugzilla.redhat.com Web UI, Database, XMLRPC Planned Outage |
August 2nd, 2008 - 9:00 AM EST - 7:00 PM EST
Date: Tue, 29 Jul 2008 00:05:42 -0400
From: Dave Lawrence <dkl(a)redhat.com>
O U T A G E R E Q U E S T F O R M
Severity Two (High)
August 2nd, 2008
9:00 AM EST - 7:00 PM EST
Estimated Time Required:
Red Hat Engineering Operations
Users of bugzilla.redhat.com and any services that rely on
bugzilla.redhat.com Web UI, Database, XMLRPC
bugzilla.redhat.com will be unavailable during the posted
time on August 2nd, 2008.
On August 2nd, bugzilla.redhat.com will go down for an
update to the latest upstream code base. During this time
the web servers will be reinstalled with the latest OS
updates as well as the latest Bugzilla code. Also the
database servers will undergo a data migration to be made
compatible with the latest Bugzilla code. The web UI,
database, and all XMLRPC services will be unavailable during
the migration. Services that rely on bugzilla.redhat.com may
not function properly during this time so please let your
users know about the outage as well.
Also please take time to point your services/scripts at our
test server https://partner-bugzilla.redhat.com to make sure
that they will still work with the new system once it goes
live. Care has been taken to make the new system backwards
compatible as much as possible with the old XMLRPC API but
still confirm that they work properly. If you encounter any
problems, please contact bugzilla-owner redhat com or file a
kbaker redhat com
Fedora-devel-announce mailing list
The OLPC School Server image is a "cli" spin for a server role, and it
is based on F7. Right now the install CDs are created using
livecd-tools, mostly due to hysterical raisins. An old-style text
installer would suit me -- and the task -- a lot better.
What I am looking for then is to be able to build an install ISO that
- fits on CD-sized media (but then, I only have a small set of packages)
- has a text installer that ideally works well on low-end hw, and supports
serial console for headless machines
- has better support for off-the-beaten path arches
- the same CD can be used for installs and upgrades
- the kickstart environment is closer to the env you get when customising
a RH build
- is resilient and produces consistent builds
- extra points if it can build F7 installers from F9 :-)
Looking around, pungi seems to be the right tool for this, but some of
the documentation options are confusing, and it doesn't seem to like
the F7 repos I've thrown at it in my early lukewarm attempts. I am
happy to debug things through (and join the fedora-buildsys-list), but
I would really appreciate some hints as to whether I'm on the right
path, or perhaps I should be using something else.
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
Anyone got any ideas why this fails (as user and root)?
repoquery --arch=src --whatrequires unique-devel
I want to update the version of unique in fedora rawhide, and need to
know what's building against the old version of the library.
I know most of us (fedora-games-list subscribers) have grown from game
packagers to contributors also doing more "serious" Fedora work.
Still Games are fun and having good Games support in Fedora is important and I
know we are all still working hard to keep our game packages in top notch state.
Given that we have all these top notch state game packages its really a shame
that we've not done a Games Spin for F-9, and we might miss the boat for F-10
too. So I'm looking for someone to pull and coordinate the efforts needed to
get a Games Spin for F-10, as always I'm willing to help but:
Is taking almost all my time so I have no time to take the lead on this one, so
any takers? The first task would be to fill in the details of:
And ask for the spin to be approved.
Thanks & Regards,
Unique in rawhide 1.0.0 breaks ABI with 0.9.4:
* Thu Jul 31 2008 Richard Hughes <rhughes(a)redhat.com> - 1.0.0-1
- Update to latest upstream version
* First stable release
* API is frozen
* D-Bus and socket backends supported
The only thing this affects in rawhide is gnome-packagekit and
gnome-power-manager, which I'll tag and chain build now. I'll update
unique in F9 in a few weeks (if there are no problems in rawhide) as
there are a couple of nice bugfixes.
a little tool came up to my mind today: How about the possibility to
strace a given binary upon execution and write the output to some file?
That could be easy to do (I've already roughly written the code down),
so I am not going to make a package of it.
To demonstrate my idea:
if you invoke the script like:
trap-strace /usr/bin/less -o /tmp/less.strace
after invoking less you cat /tmp/less.strace to see what was going on.
Does anyone else need such a tool?
If so, what package could collect it, and what constraints (language,
i/o, etc.) should it comply with?