FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-29-2010, 07:58 AM
Panu Matilainen
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

On Thu, 28 Oct 2010, Jason L Tibbitts III wrote:

>>>>>> "JN" == Joe Nall <joe@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
>
> Interesting. That's in the libcap package, which is sort of oddly named
> because it includes executables. And of course it's multilib, but the
> binaries are arch-specific which I believe is a multilib conflict.
> Probably needs the executables split out into a libcap-tools packages.
>
> I notice that rpm supports that %caps() directive in the %files list to
> specify capabilities. I don't recall seeing that before; how long ago
> did rpm grow support for it? It looks like it came in around rpm 4.7,
> so all supported Fedora releases have it. However, I'm certain it's not
> in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the
> EPEL folks will need to make a note of it.

Yup, rpm 4.7.0 was the first one to support file capabilities. It's
use is tracked with rpmlib(FileCaps) dependency, making packages utilizing
the feature uninstallable with any older rpm versions, and of course
trying to build such packages on older versions will barf out with a
errors.

It should be possible to have EPEL define a macro that turns %caps(foo)
into an %attr() with SUID bit set, but blindly enabling SUID bits might
not be such a hot idea...

- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-21-2010, 03:47 PM
Colin Walters
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

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 explain the value of capabilities, etc. I was
following along on all of this, and I understand that capabilities
have some (non-negligible) value if you don't have e.g. cap_sys_admin.
But then I got to the point where it says:

"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 permissions for root?"

So...right, "we can do these small changes, and then if we do this BIG
CHANGE, it all works!". But this feature doesn't include BIG CHANGE,
and there are no plans to, right? Or is chmod u-rwx g-rwx on the root
filesystem really in the cards?

Now,
https://fedoraproject.org/wiki/Features/LowerProcessCapabilities
appears to claim 100% completion on this for Fedora 12, but none (?)
of it happened?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-21-2010, 07:21 PM
Daniel J Walsh
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

-----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).
>
> Now, that page links to
> http://people.redhat.com/sgrubb/libcap-ng/index.html
>
> which attempts to explain the value of capabilities, etc. I was
> following along on all of this, and I understand that capabilities
> have some (non-negligible) value if you don't have e.g. cap_sys_admin.
> But then I got to the point where it says:
>
> "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 permissions for root?"
>
> So...right, "we can do these small changes, and then if we do this BIG
> CHANGE, it all works!". But this feature doesn't include BIG CHANGE,
> and there are no plans to, right? Or is chmod u-rwx g-rwx on the root
> filesystem really in the cards?
>
> Now,
> https://fedoraproject.org/wiki/Features/LowerProcessCapabilities
> appears to claim 100% completion on this for Fedora 12, but none (?)
> of it happened?

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 the app is done using them. Going to file
capabilities just limits the capabilities an application starts with to
the specified capabilities. The application developer should still drop
the capabilities once they no longer need them. It helps in the case of
a bug in an application, that does not drop capabilities.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0RDDUACgkQrlYvE4MpobNKdwCffTSEd/nmN/pwtG1d6JUdUmA6
FgwAnRK1eNQ53yLjIDwnCyFEJN4HDiF2
=1ypa
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-21-2010, 07:50 PM
Colin Walters
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh <dwalsh@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
> capabilities when the app is done using them. *Going to file
> capabilities just limits the capabilities an application starts with to
> the specified capabilities. *The application developer should still drop
> the capabilities once they no longer need them. *It helps in the case of
> a bug in an application, that does not drop capabilities.

I understand the goal of getting fewer capabilities (however, I think
switching setuid to cap_sys_admin is at best pointless, at worst an
obfuscation).

But you didn't answer my question - does the scope of this plan
include a Unix mode 005 /bin, etc. or not?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-21-2010, 08:09 PM
Daniel J Walsh
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

-----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 <dwalsh@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
>> capabilities when the app is done using them. Going to file
>> capabilities just limits the capabilities an application starts with to
>> the specified capabilities. The application developer should still drop
>> the capabilities once they no longer need them. It helps in the case of
>> a bug in an application, that does not drop capabilities.
>
> I understand the goal of getting fewer capabilities (however, I think
> switching setuid to cap_sys_admin is at best pointless, at worst an
> obfuscation).
>
> But you didn't answer my question - does the scope of this plan
> include a Unix mode 005 /bin, etc. or not?

No
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0RF50ACgkQrlYvE4MpobP4lwCgjvFcXjpCq1 BdjawVQOC6uHfL
kjwAoJ9A6lAIjLnhft+mpb4n3feZjuuw
=0JZe
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-21-2010, 08:37 PM
Miloslav Trmač
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

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 permissions for root?"
>
> So...right, "we can do these small changes, and then if we do this BIG
> CHANGE, it all works!". But this feature doesn't include BIG CHANGE,
> and there are no plans to, right?
No. The original plans didn't count with the fact that changing
permissions by owner does not require any capabilities either.

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 pointless.
Mirek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-21-2010, 09:10 PM
Colin Walters
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

2010/12/21 Miloslav Trmač <mitr@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 rather pointless.

Ah, of course. That makes sense, thanks!

But it leaves me feeling pretty uncertain about the value of trying to
subset capabilities...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-21-2010, 10:52 PM
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

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 can still trojan a system. But what if
> > we got rid of all the read/write permissions for root?"
> >
> > So...right, "we can do these small changes, and then if we do this BIG
> > CHANGE, it all works!". But this feature doesn't include BIG CHANGE,
> > and there are no plans to, right?
> No. The original plans didn't count with the fact that changing
> permissions by owner does not require any capabilities either.
>
> 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 pointless.

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?)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-21-2010, 10:59 PM
Miloslav Trmač
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

i.grok@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 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 permissions for root?"
> > >
> > > So...right, "we can do these small changes, and then if we do this BIG
> > > CHANGE, it all works!". But this feature doesn't include BIG CHANGE,
> > > and there are no plans to, right?
> > No. The original plans didn't count with the fact that changing
> > permissions by owner does not require any capabilities either.
> >
> > 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 pointless.
>
> 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?)

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.

On the other hand, passwd(1) should be able to modify it, so passwd(1)
should be set-uid "adm", not "root".

On the other hand, PAM pretty strongly assumes that is is running as
root - it is full of setuid() and other system calls that are root-only,
and arbitrary PAM modules may, and often do, assume that they are
running as root, therefore passwd(1) should be set-uid "root".

See the problem?
Mirek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-22-2010, 05:46 AM
Dick Tayter
 
Default RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)

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 pointless.

You don't even need to change permissions for root to be able to delete or change the contents of the directory.

Dick



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 11:35 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org