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
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
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.
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, say.
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
-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).
On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh dwa...@redhat.com 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
-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 dwa...@redhat.com wrote:
File capabilities just limit the number of capabilities an application
starts with. setuid app means an app starts with all 32,
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/write
2010/12/21 Miloslav Trmač m...@volny.cz:
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
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 process
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, /bin/sh is
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
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 29/10/10 04:15, Jason L Tibbitts III wrote:
JN == Joe Nallj...@nall.com 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?
-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 Nallj...@nall.com 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 Mon, 01 Nov 2010 11:04:09 -0400
Daniel J Walsh dwa...@redhat.com wrote:
On 11/01/2010 09:44 AM, Paul Howarth wrote:
On 29/10/10 04:15, Jason L Tibbitts III wrote:
JN == Joe Nallj...@nall.com writes:
JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
More to the point, I
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
On Thu, 28 Oct 2010, Jason L Tibbitts III wrote:
JN == Joe Nall j...@nall.com 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
JN == Joe Nall j...@nall.com 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
20 matches
Mail list logo
