Hey, I've been thinking about sudo passwords (particularly on publictest machines, where security holes in apps being developed cant turn up from time to time).
Could enabling NOPASSWD for sudo and disabling agent forwarding on publictest machines be a good option for lowering the possible impact if anything were to happen on the publictest machines?
The specific situation that I'm thinking about right now is: * Command execution hole in some app in testing (this has happened) * Kernel bugs like the two that have shown up in the past month * People like me regularly entering their FAS password on publictest machines and having SSH agent forwarding enabled
Maybe this is being too paranoid or not the best ultimate solution (Mike mentioned that he was looking into alternatives to entering sudo passwords, for example), but it does seem like a real risk given the freedom we allow for testing stuff out on the publictest machines.
Thanks, Ricky
On Sat, 15 Aug 2009, Ricky Zhou wrote:
Hey, I've been thinking about sudo passwords (particularly on publictest machines, where security holes in apps being developed cant turn up from time to time).
Could enabling NOPASSWD for sudo and disabling agent forwarding on publictest machines be a good option for lowering the possible impact if anything were to happen on the publictest machines?
The specific situation that I'm thinking about right now is:
- Command execution hole in some app in testing (this has happened)
- Kernel bugs like the two that have shown up in the past month
- People like me regularly entering their FAS password on publictest machines and having SSH agent forwarding enabled
Maybe this is being too paranoid or not the best ultimate solution (Mike mentioned that he was looking into alternatives to entering sudo passwords, for example), but it does seem like a real risk given the freedom we allow for testing stuff out on the publictest machines.
I'm conflicted on this, there's valid points here but also the risks are fairly low. As far as disabling agent forwarding, that's trivial to re-enable if the box gets rooted.
Specifically we're trying to protect against a rooted publictest box becoming a password harvester right?
-Mike
On Sunday, August 16 2009, Mike McGrath said:
I'm conflicted on this, there's valid points here but also the risks are fairly low. As far as disabling agent forwarding, that's trivial to re-enable if the box gets rooted.
We could add something to the security doc suggesting something like the following in ~/.ssh/config Host publictest*.fedoraproject.org ForwardAgent no
Jeremy
On 2009-08-16 09:23:37 PM, Mike McGrath wrote:
I'm conflicted on this, there's valid points here but also the risks are fairly low. As far as disabling agent forwarding, that's trivial to re-enable if the box gets rooted.
Yeah, that's true - what Jeremy suggested sounds like a better idea (and perhaps it could be added to CSI).
Specifically we're trying to protect against a rooted publictest box becoming a password harvester right?
Yup (and SSH agent harvesters as well). The goal is that if a publictest machine were compromised (since it'd probably be one of the easier targets), any damage would be confined to that machine as much as possible.
Thanks, Ricky
On Mon, 17 Aug 2009, Ricky Zhou wrote:
On 2009-08-16 09:23:37 PM, Mike McGrath wrote:
I'm conflicted on this, there's valid points here but also the risks are fairly low. As far as disabling agent forwarding, that's trivial to re-enable if the box gets rooted.
Yeah, that's true - what Jeremy suggested sounds like a better idea (and perhaps it could be added to CSI).
Specifically we're trying to protect against a rooted publictest box becoming a password harvester right?
Yup (and SSH agent harvesters as well). The goal is that if a publictest machine were compromised (since it'd probably be one of the easier targets), any damage would be confined to that machine as much as possible.
On a related note, I would like to have a policy of rebuilding the test boxes more often then we do. Just a thought.
-Mike
On 2009-08-17 02:44:58 PM, Mike McGrath wrote:
On a related note, I would like to have a policy of rebuilding the test boxes more often then we do. Just a thought.
Agreed. publictest15 is nearing a year old, which I think is way too long for a publictest machine. It has all sorts of junk on it now (like the errors that Eric got about /opt/zimbra when trying to setup zikula).
Here s a summary of our currently running publictest machines and the date they were built on (from an rpm -qa --last | tail -1):
publictest1: Sun 10 May 2009 09:46:49 PM GMT publictest2: Fri 29 May 2009 11:06:26 PM UTC publictest3: Thu 11 Jun 2009 09:25:56 PM UTC publictest6: Tue 23 Jun 2009 08:34:50 PM UTC publictest7: Tue 30 Jun 2009 08:24:36 PM UTC publictest10: Tue 02 Dec 2008 10:45:16 PM UTC publictest14: Tue 16 Dec 2008 10:38:09 PM UTC publictest15: Thu 28 Aug 2008 06:26:33 PM UTC publictest16: Thu 23 Oct 2008 06:14:22 PM UTC
All the 2008 ones should probably be rebuilt when possible - any thoughts as to what a good policy for this would be? Maybe after ~4-6 months, we should stop putting new projects on publictest machines, and rebuild them once all current projects are finished?
The wiki pages could also be great for tracking some of this stuff.
Thanks, Ricky
On Mon, 17 Aug 2009, Ricky Zhou wrote:
On 2009-08-17 02:44:58 PM, Mike McGrath wrote:
On a related note, I would like to have a policy of rebuilding the test boxes more often then we do. Just a thought.
Agreed. publictest15 is nearing a year old, which I think is way too
Ugh, a year old. /me checks his calendar.
My god has it been a year already?
https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.ht...
wow.
-Mike
On Mon, Aug 17, 2009 at 03:36:40PM -0500, Mike McGrath wrote:
On Mon, 17 Aug 2009, Ricky Zhou wrote:
On 2009-08-17 02:44:58 PM, Mike McGrath wrote:
On a related note, I would like to have a policy of rebuilding the test boxes more often then we do. Just a thought.
Agreed. publictest15 is nearing a year old, which I think is way too
Ugh, a year old. /me checks his calendar.
My god has it been a year already?
https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.ht...
wow.
It seems like only a few months since... oh wait, it was:
https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.htm...
Agreed. publictest15 is nearing a year old, which I think is way too long for a publictest machine. It has all sorts of junk on it now (like the errors that Eric got about /opt/zimbra when trying to setup zikula).
Yes, It have 15 different calender setup ad other related things. So it already had zikula and probably zimbra too. ;) Notify me if you plan to rebuild it. The webcalender, on which testing is pending, is there too.
infrastructure@lists.fedoraproject.org