Preventing ctrl-c from blocking CVS commit messages
by Ricky Zhou
Hey, I'm currently testing a solution for the problem where one can
prevent CVS commit mail from going out by pressing ctrl-c during the
commit.
To do this, I built a version of CVS with signal handling disabled and
made a wrapper script for cvs server that traps SIGINT and some other
things.
I'd appreciate if people can test and try to abuse/break this setup :-),
so I have a test repo setup. To test this, you need to be in
sysadmin-test:
1. Prepend your ~/.ssh/authorized_keys file on
publictest10.fedoraproject.org with:
command="/home/fedora/ricky/test.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
(make sure not to accidentally lock yourself out with this)
2. Checkout the test module with:
cvs -d :ext:username@publictest10.fedoraproject.org/home/fedora/ricky/repo co test
3. Try to make a commit without it getting logged in
/home/fedora/ricky/repo/CVSROOT/commitlog
Feel free to try clever/evil things to test this out.
Thanks,
Ricky
15 years
Outstanding F11 tickets
by Mike McGrath
So there are a number of F11 tickets outsanding right now assigned to a
wide range of people.
https://fedorahosted.org/fedora-infrastructure/query?status=new&status=as...
(http://tinyurl.com/dmb88h)
Please do log in, close/fix the ticket, or give it a Fedora 12 milestone
with an explanation of why it can't / shouldn't be done by F12. As always
much of our team consists of volunteers and not having enough time is a
completely valid reason for a project to not be complete.
If you are on the below list you have a ticket assigned to you. If you
are unable to work in the ticket any longer please find a replacement or
assign it to "nobody"
toshio, jcollie, mmcgrath, sysadmin-hosted-members, ausil, fchiulli,
bretm, lmacken, jsmith, ricky, nigelj, ianweller, huzaifas, boodle,
mdomsch, santosp, webmaster, ausil, sts, laxathom.
-Mike
15 years
SELinux lockdown
by Luke Macken
Hey everyone,
So I've been doing a lot of SELinux/audit related work behind the scenes
within our infrastructure for a while now, working closely with Dan
Walsh and Steve Grubb. It's taken a lot of patience and hard work, but
we're finally at the point where we can start switching large portions
of our infrastructure over to SELinux Enforcing mode.
The following server groups are now fully enforcing:
o gateway
o people
o planet
o fas
o collab
o releng
o db
o torrent
o dns
These are all groups of machines that have not had any SELinux
denials in at least a month. If you notice any issues with
regard to these groups, please speak up.
I will be keeping a close eye on these machines, and I encourage anyone
that is interested to do the same. I threw together a little tool that
I've been using to monitor & manage SELinux on our machines. It uses
func, and allows you to do the following:
Get the SELinux status:
selinux-overlord.py --status
Display all enforced denials:
selinux-overlord.py --enforced-denials
Dump all raw AVCs to disk. Each minion will have it's own file:
selinux-overlord.py --dump-avcs
Upgrade the SELinux policy RPMs:
selinux-overlord.py --upgrade-policy
It defaults to querying all minions, but you can specify groups of them
if you wish:
selinux-overlord.py --status app* db*
This script should ideally be it's own func module, but in the mean time
I added it to the fedora-infrastructure git repository:
http://git.fedorahosted.org/git/?p=fedora-infrastructure.git;a=blob_plain...
More information on our SELinux deployment can be found in our
[out of date] SOP: http://fedoraproject.org/wiki/Infrastructure/SOP/SELinux
luke
15 years
Multi-factor authentication
by Mike McGrath
I had intended to send this earlier but am only getting around to it.
As per our discussion online (this is unrelated to the other thread about
ldap and wanting a C coder.
Dennis and I have started looking at yubikey for authentication. After
some discussion in the last meeting these are some of the talking points.
As of right now nothing is set in stone but yubikeys are a strong front
runner.
* Will likely be required for sysadmin-main and probably a few other
highly sensitive groups (package signing)
* Will probably be required for those groups on specific high target
servers.
* Will likely be an additional layer of authentication instead of a
replacement.
* Possibly required for sudo access
* Possibly required for shell access
* Concerns about SPOF (yubikeys in particular require a central server)
* Might be optional for other contributors wanting to use additional
security.
* Obviously will require only Free Software.
* kerberos was discussed, some for some against. The primary hangup
being people who use kerberos as their $DAYJOB will have conflicts when
working in Fedora.
* Concerns over what to do when a key is stolen[1] Though phone numbers
were mentioned as an additional verification level.
* Still unclear how to make the keys
* Implementation details still unclear though it was generally
considered that "yubikey + ssh key" were both "something you have".
Meaning it'd be "yubikey + fas password" "Something you have +
something you know" as is common with most multifactor authentication
mechanisms.
My initial looks at yubikey are pretty promising, from knowing nothing to
being able to ssh using the yubikey took only about 15 minutes. It'll
take less now that dgilmore has the software packaged like pam_yubico.
Questions comments?
-Mike
[1] This is an issue even with non keys, it's nearly impossible for us to
verify someone is who they say they are if they no longer have access to
their email address, even that's not really 'proof'.
15 years
Re: Statistics problem
by Paul W. Frields
On Mon, Apr 27, 2009 at 07:43:01PM -0800, Jeff Spaleta wrote:
> On Mon, Apr 27, 2009 at 6:30 PM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
> > On Mon, Apr 27, 2009 at 6:26 PM, Paul W. Frields <stickster(a)gmail.com> wrote:
> >> I did two counts, one for DVD and Live without uniq'ing the IP
> >> addresses doing the retrievals (because there could be multiple
> >> downloads from people behind firewalls), and one with. In both cases
> >> I think the numbers are very significantly higher than our current
> >> stats show. The raw numbers per day since F10 release are attached.
> >
> > All those numbers in the txt use the "corrected" approach?
>
> Just to be clear.. what where the stats showing before? Just the
> unique DVD counts?
The download numbers before were using the direct download command
shown on this wiki page:
https://fedoraproject.org/wiki/Statistics/Commands
There was at least one major problem with that command; the Fedora 10
Live ISO filenames don't start with "Fedora-10," they start with
"F10," meaning we weren't counting them *at all*. So I've included
two counts, one for the DVD and one for the Live ISO as clicked from
the get-fedora page. (Other spins, as far as I can tell, are done via
torrent and we're capturing those statistics from the tracker
elsewhere.)
The second problem may not be a real problem -- it's that we are
uniq-ing the IP addresses doing the downloading. That method has the
potential to cut out legitimate, repetitive downloads from inside a
firewall. I'd feel better cutting those ticks out if they were
separated by a very short timeframe. Then we could be reasonably
certain they were caused by repeated clicks, rather than actual
separate downloads. In the interest of a conservative approach, I'm
willing to stick with uniq-ing the stats, but I produced both sets of
numbers anyway.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
15 years