ons 2010-12-22 klockan 00:59 +0100 skrev Miloslav Trmač:
> This is possible, but it would be a much larger change to the system.
> To take a particular example, look at /etc/shadow.
>
> It needs to be protected against attackers, so it should not be owned by
> root - let's make it owned by "adm",
tis 2010-12-21 klockan 18:52 -0500 skrev i.g...@comcast.net:
> Ok, so who says that the files must be owned by root? Make them owned by
> some other user -- say, bin? (or does that have another use that my
> google search isn't coming up with?)
Better to make the process not run as root imho.
Re
tis 2010-12-21 klockan 11:47 -0500 skrev Colin Walters:
> "But they still have uid 0, which typical system installation allows
> root to do things. For example, /bin/sh is 0755 and /bin is also 0755
> perms. A disarmed root process can still trojan a system. But what if
> we got rid of all the rea
I know that you're not proposing this, but can I just interject that
if you make any of these files unreadable by 'other', then supermin
appliance building will break.
http://libguestfs.org/febootstrap.8.html#supermin_appliances
I think supermin appliances are a sufficiently useful mechanism to
g
2010/12/21 Miloslav Trmač:
> If an attacker were controlling a process running with uid 0 and no
> capabilities at all, and /bin/sh were 0555, nothing prevents the
> attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes
> any attempts to change the file permissions rather pointl
i.g...@comcast.net píše v Út 21. 12. 2010 v 18:52 -0500:
> On Tue, Dec 21, 2010 at 10:37:44PM +0100, Miloslav Trmač wrote devel:
> > Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500:
> > > "But they still have uid 0, which typical system installation allows
> > > root to do things. For example, /
On Tue, Dec 21, 2010 at 10:37:44PM +0100, Miloslav Trmač wrote devel:
> Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500:
> > "But they still have uid 0, which typical system installation allows
> > root to do things. For example, /bin/sh is 0755 and /bin is also 0755
> > perms. A disarmed root p
2010/12/21 Miloslav Trmač :
> If an attacker were controlling a process running with uid 0 and no
> capabilities at all, and /bin/sh were 0555, nothing prevents the
> attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes
> any attempts to change the file permissions rather point
Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500:
> "But they still have uid 0, which typical system installation allows
> root to do things. For example, /bin/sh is 0755 and /bin is also 0755
> perms. A disarmed root process can still trojan a system. But what if
> we got rid of all the read/wri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/21/2010 03:50 PM, Colin Walters wrote:
> On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh wrote:
>>
>> File capabilities just limit the number of capabilities an application
>> starts with. setuid app means an app starts with all 32, a couple of
On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh wrote:
>
> File capabilities just limit the number of capabilities an application
> starts with. setuid app means an app starts with all 32, a couple of
> new ones, capabilities. Then it is up to the app developer to drop the
> capabilities when th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/21/2010 11:47 AM, Colin Walters wrote:
> Pardon the thread necromancy,
>
> So recently I had cause to look at
> http://fedoraproject.org/wiki/Features/RemoveSETUID
> again (I was investigating the X server permissions for an unrelated reason).
>
Pardon the thread necromancy,
So recently I had cause to look at
http://fedoraproject.org/wiki/Features/RemoveSETUID
again (I was investigating the X server permissions for an unrelated reason).
Now, that page links to
http://people.redhat.com/sgrubb/libcap-ng/index.html
which attempts to explai
On Mon, 01.11.10 20:28, Richard W.M. Jones (rjo...@redhat.com) wrote:
>
> On Mon, Nov 01, 2010 at 07:19:15PM +, Paul Howarth wrote:
> > Any suggestions?
>
> We've encountered some funny things about tmpfs before: It doesn't
> support O_DIRECT at all, for example, necessitating workarounds in
On Thu, Oct 28, 2010 at 11:14:08AM +0300, Pekka Pietikainen wrote:
> On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
> > This feature is now approved and I see bugs get filed. The documentation
> > and
> > guidelines are very incomplete. How does one figure out which file
> > cap
Here's another problem:
Prelink erases file-based capabilities.
https://bugzilla.redhat.com/show_bug.cgi?id=456105
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages
fre 2010-10-29 klockan 08:32 -0400 skrev James Antill:
> I don't think you need to display them, just display something that
> says "this is more than it seems" ... like ACLs. Something as simple as
> "-rwcr-xr-x." instead of "-rwsr-xr-x." for setuid.
I.e. kind of like what "ls --color" does?
R
On Mon, Nov 01, 2010 at 07:19:15PM +, Paul Howarth wrote:
> Any suggestions?
We've encountered some funny things about tmpfs before: It doesn't
support O_DIRECT at all, for example, necessitating workarounds in
libguestfs/qemu. Just speculating, but maybe it doesn't support
extended attribute
On Mon, 01 Nov 2010 11:04:09 -0400
Daniel J Walsh wrote:
> On 11/01/2010 09:44 AM, Paul Howarth wrote:
> > On 29/10/10 04:15, Jason L Tibbitts III wrote:
> >>> "JN" == Joe Nall writes:
> >>
> >> JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
> >>
> More to the point, I can e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/2010 09:44 AM, Paul Howarth wrote:
> On 29/10/10 04:15, Jason L Tibbitts III wrote:
>>> "JN" == Joe Nall writes:
>>
>> JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
>>
More to the point, I can easily see the setuid bit
On 29/10/10 04:15, Jason L Tibbitts III wrote:
>> "JN" == Joe Nall writes:
>
> JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
>
>>> More to the point, I can easily see the setuid bit easily on a
>>> binary.
>>> How do I tell if these strange/hidden "capabilities" are
>>> present o
On Fri, 2010-10-29 at 12:05 -0400, Matthew Miller wrote:
> On Fri, Oct 29, 2010 at 12:41:07PM +0100, Daniel P. Berrange wrote:
> > You only have 3 letters to remember the name of and you encounter them on
> > a daily basis, so its easily rememberable. Give every capability even a 5
> > letter long
On Fri, Oct 29, 2010 at 07:00:54PM +0200, Patrick MONNERAT wrote:
> I'm color-blind (I see colors but I don't distinguish them) quite
> strongly. In addition, I usually work on a reverse intensity terminal
> (light on dark), that makes ls colors anti-ergonomic.
>
> I already considered the introdu
On Fri, 2010-10-29 at 12:31 -0400, Matthew Miller wrote:
>
> I think that's something we can live with. Colorizing is already significant
> overhead, and if performance is important, don't do it:
>
I'm color-blind (I see colors but I don't distinguish them) quite
strongly. In addition, I usuall
On Fri, Oct 29, 2010 at 06:16:32PM +0200, Andreas Schwab wrote:
> >From coreutils/src/ls.c:
> /* Note has_capability() adds around 30% runtime to `ls --color` */
> Andreas.
I think that's something we can live with. Colorizing is already significant
overhead, and if performance is important
Matthew Miller writes:
> On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
>> Is there any particular reason, the regular tools that users already use
>> cannot be modified to display the appropriate info, like SELinux and -Z
>> argument.
>
> FWIW, colorized ls seems to already reco
On Fri, Oct 29, 2010 at 12:41:07PM +0100, Daniel P. Berrange wrote:
> You only have 3 letters to remember the name of and you encounter them on
> a daily basis, so its easily rememberable. Give every capability even a 5
> letter long code and few will ever be able to remember what they mean.
Perha
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
> Is there any particular reason, the regular tools that users already use
> cannot be modified to display the appropriate info, like SELinux and -Z
> argument.
FWIW, colorized ls seems to already recognize them. Setuid binaries are
g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/2010 08:32 AM, James Antill wrote:
> On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote:
>> On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
>>> On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/2010 08:32 AM, James Antill wrote:
> On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote:
>> On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
>>> On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
>>>
On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote:
> On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
> > On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
> >
> > >
> > >
> > > You want the libcap-ng-utils RPMs which provides a bunch of useful tools
> > > for th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/2010 07:18 AM, Daniel P. Berrange wrote:
> On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
>> On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
>>
>>>
>>>
>>> You want the libcap-ng-utils RPMs which provides a bunch o
On Fri, Oct 29, 2010 at 04:55:44PM +0530, Rahul Sundaram wrote:
> On Fri, Oct 29, 2010 at 4:48 PM, Daniel P. Berrange wrote:
>
> >
> > There are 32 possible capabilites, so you'll quickly exceed the width
> > of terminals just listing capabilities, in this format. You could try
> > and decide on
On Fri, Oct 29, 2010 at 4:48 PM, Daniel P. Berrange wrote:
>
> There are 32 possible capabilites, so you'll quickly exceed the width
> of terminals just listing capabilities, in this format. You could try
> and decide on shortened names to < 5 characters each, but it isn't
> going to be so readab
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
> On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
>
> >
> >
> > You want the libcap-ng-utils RPMs which provides a bunch of useful tools
> > for this, filecap, netcap, pscap, etc.
> >
>
> Is there any particular reason, t
On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
>
>
> You want the libcap-ng-utils RPMs which provides a bunch of useful tools
> for this, filecap, netcap, pscap, etc.
>
Is there any particular reason, the regular tools that users already use
cannot be modified to display the appropri
On Thu, Oct 28, 2010 at 11:08:00PM +0100, Richard W.M. Jones wrote:
> On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
> > On 10/28/2010 01:11 AM, Kevin Fenzi wrote:
> >
> > * #480 F15Feature - RemoveSETUID (
> > http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik,
> >
On Thu, 28 Oct 2010, Jason L Tibbitts III wrote:
>> "JN" == Joe Nall writes:
>
> JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
>
>>> More to the point, I can easily see the setuid bit easily on a
>>> binary.
>>> How do I tell if these strange/hidden "capabilities" are
>>> present
> "JN" == Joe Nall writes:
JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
>> More to the point, I can easily see the setuid bit easily on a
>> binary.
>> How do I tell if these strange/hidden "capabilities" are
>> present on a binary? 'ls' doesn't mention anything.
JN> getcap
On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
> On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
>> On 10/28/2010 01:11 AM, Kevin Fenzi wrote:
>>
>> * #480 F15Feature - RemoveSETUID (
>> http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik,
>> 19:15:16)
>> * A
On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
> On 10/28/2010 01:11 AM, Kevin Fenzi wrote:
>
> * #480 F15Feature - RemoveSETUID (
> http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik,
> 19:15:16)
> * AGREED: the feature is approved. (nirik, 19:26:46)
>
>
> Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/28/2010 04:14 AM, Pekka Pietikainen wrote:
> On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
>> This feature is now approved and I see bugs get filed. The documentation and
>> guidelines are very incomplete. How does one figure
On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
> This feature is now approved and I see bugs get filed. The documentation and
> guidelines are very incomplete. How does one figure out which file
> capabilities are needed by the programs I maintain that currently use setuid?
> He
On 10/28/2010 01:11 AM, Kevin Fenzi wrote:
* #480 F15Feature - RemoveSETUID (
http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik,
19:15:16)
* AGREED: the feature is approved. (nirik, 19:26:46)
This feature is now approved and I see bugs get filed. The documentation
and guidel
===
#fedora-meeting: FESCO (2010-10-27)
===
Meeting started by nirik at 18:30:00 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-10-27/fesco.2010-10-27-18.30.log.html
Meeting summary
-
45 matches
Mail list logo
