On Wed, Jul 29, 2009 at 9:32 AM, Stephen Smalleys...@tycho.nsa.gov wrote:
If you want something more akin to privilege bracketing within a
program, then a closer analog in SELinux would be setcon(3) to switch to
a more restricted domain. But in general our goal is to enforce
security goals at
On Mon, Aug 3, 2009 at 12:38 PM, Till Maasopensou...@till.name wrote:
$ sudo -i
sudo: /etc/sudoers is mode 00, should be 0440
sudo: no valid sudoers sources found, quitting
This is sudo checking the permissions of it's own sudoers file. Since
they aren't what it expects, it bails.
--
On Thu, 2009-08-13 at 21:27 -0400, Steve Grubb wrote:
On Thursday 13 August 2009 05:53:37 pm John Poelstra wrote:
Can you update the feature page to reflect the reduced scope of the
feature and its completion percentage? All I see since FESCo met was
the change to the detailed description
CAP_DAC_OVERRIDE,
but to only allow it from logins or su/sudo.
As discussed at the Fesco meeting last week, the lower process capabilities
project is going to reduce the scope of this part of the proposal. At this
point, we are going to tighten up perms on the directories in $PATH,
/lib[64],
/boot
On Thursday 13 August 2009 05:53:37 pm John Poelstra wrote:
Can you update the feature page to reflect the reduced scope of the
feature and its completion percentage? All I see since FESCo met was
the change to the detailed description related to the permissions.
That *is* the reduction in
On 31/07/09 01:09, Matthew Woehlke wrote:
Bill McGonigle wrote:
What's it going to take to make most
people who shut off SELinux stop doing that?
...being able to install bleeding-edge devel KDE to
/usr/local/my-kde-install and be able to use that as my primary desktop.
I guess that would -
On 08/05/2009 08:02 AM, Paul Howarth wrote:
http://danwalsh.livejournal.com/27571.html
This is really nice.
To partially answer my own question, Dan keeps coming up with great
stuff that seems essential for average admins to maintain an SELinux box.
-Bill
--
Bill McGonigle, Owner
Bill McGonigle wrote:
What's it going to take to make most
people who shut off SELinux stop doing that?
...being able to install bleeding-edge devel KDE to
/usr/local/my-kde-install and be able to use that as my primary desktop.
I guess that would - at best - take some kind of smart
On Tue, 2009-07-28 at 20:13 -0500, Serge E. Hallyn wrote:
Quoting Bill McGonigle (b...@bfccomputing.com):
On 07/28/2009 04:11 PM, Chris Adams wrote:
Still, is such a change less severe than changing what root means? Is
Fedora that committed to SELinux? What's it going to take to make most
On Tue, 2009-07-28 at 17:53 -0400, Bill McGonigle wrote:
On 07/28/2009 04:11 PM, Chris Adams wrote:
AFAIK SELinux introduces additional controls and does not replace or
override existing controls. I'm pretty sure non-root still can't
directly listen on a low-numbered port.
For some
On Wed, 29 Jul 2009, Stephen Smalley wrote:
So I think the only piece of the proposal that is orthogonal to SELinux
is privilege bracketing within the program (dropping caps after use).
But the changes to the file and directory permissions seem more
questionable.
Once we have access
On Wed, 2009-07-29 at 23:01 +1000, James Morris wrote:
On Wed, 29 Jul 2009, Stephen Smalley wrote:
So I think the only piece of the proposal that is orthogonal to SELinux
is privilege bracketing within the program (dropping caps after use).
But the changes to the file and directory
On Wed, 2009-07-29 at 09:10 -0400, Stephen Smalley wrote:
On Wed, 2009-07-29 at 23:01 +1000, James Morris wrote:
On Wed, 29 Jul 2009, Stephen Smalley wrote:
So I think the only piece of the proposal that is orthogonal to SELinux
is privilege bracketing within the program (dropping caps
Quoting Stephen Smalley (s...@tycho.nsa.gov):
On Tue, 2009-07-28 at 17:53 -0400, Bill McGonigle wrote:
On 07/28/2009 04:11 PM, Chris Adams wrote:
AFAIK SELinux introduces additional controls and does not replace or
override existing controls. I'm pretty sure non-root still can't
On Wednesday 29 July 2009 09:49:29 am Serge E. Hallyn wrote:
There was a patch floated on selinux list circa June 2007 that would
have allowed SELinux to directly grant capabilities. But it met a
certain amount of resistance from people concerned about the
implications of changing the
On Jul 29, 2009, at 8:49 AM, Serge E. Hallyn wrote:
The same thing can happen at the moment with capabilities for an NFS
rootfs,
prelink killed file caps on fedora last time I checked. Makes them
useless for general purpose app protection.
On 07/29/2009 10:06 AM, Steve Grubb wrote:
There is also the argument that what we've been teaching people for years is
that SE Linux strips away privileges and doesn't grant them. Changing the
model would be somewhat confusing.
Just to play the devil's hair-splitting advocate, if the kernel
On 07/26/2009 07:32 PM, Steve Grubb wrote:
If we change the bin directory to 005, then root cannot write to that
directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this
project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, but
to only allow it from
Once upon a time, Bill McGonigle b...@bfccomputing.com said:
Doesn't SELinux already support allowing non-root users to have access
to low-numbered ports?
AFAIK SELinux introduces additional controls and does not replace or
override existing controls. I'm pretty sure non-root still can't
On 07/28/2009 04:11 PM, Chris Adams wrote:
AFAIK SELinux introduces additional controls and does not replace or
override existing controls. I'm pretty sure non-root still can't
directly listen on a low-numbered port.
For some reason I thought it was possible with MAC, but I can't find
On Tue, Jul 28, 2009 at 17:53:53 -0400,
Bill McGonigle b...@bfccomputing.com wrote:
One simple alternative, sure to be unpopular with many, would be to
patch the kernel to skip the low-numbered-port enforcement if SELinux is
running in enforcing mode, and ship policies that do the right
Quoting Bill McGonigle (b...@bfccomputing.com):
On 07/28/2009 04:11 PM, Chris Adams wrote:
Still, is such a change less severe than changing what root means? Is
Fedora that committed to SELinux? What's it going to take to make most
people who shut off SELinux stop doing that?
Moving to
On Sun, 26 Jul 2009, Steve Grubb wrote:
The basic idea goes something like this: We would like to do something to
prevent priv escalation for processes running as root. For this example, lets
take cupsd to be a good case in point. If the attacker can find a vuln with
cupsd, then they can
Quoting Steve Grubb (sgr...@redhat.com):
On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote:
I trust you meant to write 0555?
No, I really mean 005 so that root daemons are using public permissions.
Admins of course have DAC_OVERRIDE and can do anything. Try the script in a
VM and
On Monday 27 July 2009 09:11:33 am Serge E. Hallyn wrote:
Quoting Steve Grubb (sgr...@redhat.com):
On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote:
I trust you meant to write 0555?
No, I really mean 005 so that root daemons are using public
permissions. Admins of course have
On Mon, 2009-07-27 at 19:25 +1000, James Morris wrote:
On Sun, 26 Jul 2009, Steve Grubb wrote:
The basic idea goes something like this: We would like to do something to
prevent priv escalation for processes running as root. For this example,
lets
take cupsd to be a good case in point.
On Mon, Jul 27, 2009 at 5:29 PM, Adam Jacksona...@redhat.com wrote:
On Mon, 2009-07-27 at 19:25 +1000, James Morris wrote:
On Sun, 26 Jul 2009, Steve Grubb wrote:
The basic idea goes something like this: We would like to do something to
prevent priv escalation for processes running as root.
Hello,
I wanted to send an email to give everyone a heads up about a project I'm
working on. You can find the write-up here:
https://fedoraproject.org/wiki/Features/LowerProcessCapabilities
The basic idea goes something like this: We would like to do something to
prevent priv escalation for
Steve Grubb sgr...@redhat.com writes:
The directory for /bin is 0755 root root. So, even if we drop all
capabilities, the root acct can still trojan a system.
If we change the bin directory to 005, then root cannot write to that
directory unless it has the CAP_DAC_OVERRIDE capability.
I
On Sunday 26 July 2009 08:38:45 pm Tom Lane wrote:
Steve Grubb sgr...@redhat.com writes:
The directory for /bin is 0755 root root. So, even if we drop all
capabilities, the root acct can still trojan a system.
If we change the bin directory to 005, then root cannot write to that
On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote:
I trust you meant to write 0555?
No, I really mean 005 so that root daemons are using public permissions.
Admins of course have DAC_OVERRIDE and can do anything. Try the script in a
VM and tell me if there are any problems you see.
I
Steve Grubb sgr...@redhat.com writes:
On Sunday 26 July 2009 08:38:45 pm Tom Lane wrote:
I trust you meant to write 0555?
No, I really mean 005 so that root daemons are using public permissions.
What's the point? The most you will accomplish is to confuse people
(and perhaps programs too).
On Sunday 26 July 2009 09:01:14 pm Tom Lane wrote:
0005 is certainly not meaningfully more secure than 0555.
There are some secrets in files that semi-trusted root apps should not have
access to.
-Steve
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
33 matches
Mail list logo
