Hello,
I saw capabilities and acl patches for ext2/3 enter -mm. Is it possible
now to give an executable (that lives on an ext2/ext3 fs) the necessary
rights to use SCHED_FIFO without being setuid root? Could someone give
me some pointers for these topics (capabilities support in linux, acl)?
regards, Stefan
--
----> http://www.shockfrosted.org
On Wed, 16 Oct 2002, Stefan Schwandter wrote:
> I saw capabilities and acl patches for ext2/3 enter -mm. Is it possible
> now to give an executable (that lives on an ext2/ext3 fs) the necessary
> rights to use SCHED_FIFO without being setuid root? Could someone give
> me some pointers for these topics (capabilities support in linux, acl)?
The program needs CAP_SYS_NICE capability. Look at http://www.linsec.org
or http://www.lids.org
Greetings
On Wed, Oct 16, 2002 at 05:44:59PM +0200, Stefan Schwandter wrote:
>
> I saw capabilities and acl patches for ext2/3 enter -mm. Is it possible
> now to give an executable (that lives on an ext2/ext3 fs) the necessary
> rights to use SCHED_FIFO without being setuid root? Could someone give
> me some pointers for these topics (capabilities support in linux, acl)?
The patchs which I've been working on do not support capabilities;
just extended attributes.
Personally, I'm not so convinced that capabilities are such a great
idea. System administrators have a hard enough time keeping 12 bits
of permissions correct on executable files; with capabilities they
have to keep track of several hundred bits of capabilties flags, which
must be set precisely correctly, or the programs will either (a) fail
to function, or (b) have a gaping huge security hole.
This probablem could be solved with some really scary, complex user
tools (which no one has written yet). Alternatively you could just
let programs continue to be setuid root, but modify the executable to
explicitly drop all the capabilities except for the ones that are
actually needed as one of the first things that executable does. It
perhaps only gives you 90% of the benefits of the full-fledged
capabilities model, but it's much more fool proof, and much easier to
administer.
- Ted
On Wed, 2002-10-16 at 22:26, Theodore Ts'o wrote:
> On Wed, Oct 16, 2002 at 05:44:59PM +0200, Stefan Schwandter wrote:
> >
> > I saw capabilities and acl patches for ext2/3 enter -mm. Is it possible
> > now to give an executable (that lives on an ext2/ext3 fs) the necessary
> > rights to use SCHED_FIFO without being setuid root? Could someone give
> > me some pointers for these topics (capabilities support in linux, acl)?
>
> The patchs which I've been working on do not support capabilities;
> just extended attributes.
>
> Personally, I'm not so convinced that capabilities are such a great
> idea. System administrators have a hard enough time keeping 12 bits
> of permissions correct on executable files; with capabilities they
> have to keep track of several hundred bits of capabilties flags, which
> must be set precisely correctly, or the programs will either (a) fail
> to function, or (b) have a gaping huge security hole.
While working with LIDS in it's early stages of implementation, and
having written some documentation around CAPs and extended attributes,
as well as managing that environment, I see value in CAPs, but I see it
a difficult task to say, manage 100 servers with very tight CAPs set.
> This probablem could be solved with some really scary, complex user
> tools (which no one has written yet).
Looking at CA Unicenter, they have an ACLs and CAPs product which does
centralized management of those attributes to keep the configs sane
across your environment. Not trying to advertise for them, but the point
is, if a commercial product exists to do this, then it should be highly
possible in the OSS community as well.
> Alternatively you could just
> let programs continue to be setuid root, but modify the executable to
> explicitly drop all the capabilities except for the ones that are
> actually needed as one of the first things that executable does.
To make management easy for the admins when I dealt with LIDS and making
it *very* tight, I had to write several wrappers, replace commands, etc
so they ran chrooted automatically, etc. It was a PITA. Cool when it
worked, but it was still a PITA.
> It perhaps only gives you 90% of the benefits of the full-fledged
> capabilities model, but it's much more fool proof, and much easier to
> administer.
Perhaps exntending the security module to actually have a centralized
host configuration utility, using say AES or diffie-hellman and SSL or
SSH to do the configuration management of this. Centralizing, or
distributing the management of this, but with a decided upon security
architecture is what, imho, will actually make this type of
configuration very useable, and manageable.
> - Ted
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
"Theodore Ts'o" <[email protected]> writes:
> Personally, I'm not so convinced that capabilities are such a great
> idea. System administrators have a hard enough time keeping 12 bits
> of permissions correct on executable files; with capabilities they
> have to keep track of several hundred bits of capabilties flags, which
So you claim, system administrators are stupid people?
> must be set precisely correctly, or the programs will either (a) fail
> to function,
Which you will notice very fast.
> or (b) have a gaping huge security hole.
Which is not worse, but possibly a lot better, than setuid root.
> This probablem could be solved with some really scary, complex user
> tools (which no one has written yet). Alternatively you could just
> let programs continue to be setuid root, but modify the executable to
> explicitly drop all the capabilities except for the ones that are
> actually needed as one of the first things that executable does. It
Which isn't convincing, either. The benefit of capabilities is to
administer your system _without_ relying on someone else doing a
decent job.
> perhaps only gives you 90% of the benefits of the full-fledged
> capabilities model, but it's much more fool proof, and much easier to
> administer.
With capabilities you don't have to resort to programming, which _is_
already an easier way to administer. This also means, distribution
builders, who may not be coders, can contribute to enhance security.
Maybe this sounds like a plea for capabilities and maybe it is, but I
just want to put some things straight. Unless there's something
better, I stay with capabilities.
To be more constructive, I want to point to
<http://www.linux.it/~md/software/ssd.tgz>. This is a modified
start-stop-daemon, which allows to change capabilities. With this
really scary, complex user tool (which to some extent it is, when you
look at the code), I was able to drop all the capabilities except for
the ones that are actually needed. ;-)
Regards, Olaf.
On Thursday 17 October 2002 12:37, Olaf Dietsche wrote:
> "Theodore Ts'o" <[email protected]> writes:
> > Personally, I'm not so convinced that capabilities are such a great
> > idea. System administrators have a hard enough time keeping 12 bits
> > of permissions correct on executable files; with capabilities they
> > have to keep track of several hundred bits of capabilties flags, which
>
> So you claim, system administrators are stupid people?
Filesystem capabilities move complexity out of applications into the file
system (=system configuration), so the admins have to deal with an additional
task.
>From a security point of view suid root applications that are dropping
capabilities voluntarily aren't much different from plain old suid root apps;
there may still be exploitable bugs before the code that drops capabilities
(which doesn't mean that apps shouldn't drop capabilities). With capabilities
the kernel ensures that applications cannot exceed their capabilities.
I think the remaining questions really are:
- how to populate the database of capabilities needed by apps.
(Pavel Machek has started this as part of elfcap [which is a bad
idea], see http://atrey.karlin.mff.cuni.cz/~pavel/caps/capbase.txt)
- how to make maintaining / monitoring tight capabilities as
effortless as possible.
- how to set up capabilities when users log in (which users are
granted which capabilities; this can be used to split up the role
of root.)
- (maybe some more)
> > must be set precisely correctly, or the programs will either (a) fail
> > to function,
>
> Which you will notice very fast.
Well perhaps not, the admin gets overloaded with requests/complaints, and
finally decides to discard FS caps.
> > or (b) have a gaping huge security hole.
>
> Which is not worse, but possibly a lot better, than setuid root.
It's worse if apps stop dropping capabilities and instead rely on the caller.
--Andreas.
On Thu, Oct 17, 2002 at 02:05:26PM +0200, Stefan Schwandter wrote:
> Ah, ok... I thought that things work like this: the capabilities support
> already is in the kernel, and to give an app a particular capability,
> one has to add a particalar extended attribute to the application
> executable. So I'm wrong here it seems?
First of all, you can't use a standard user extended attribute, since
anyone with write access to the file will be allowed to set the
extended attribute. This isn't good if you're going to be granting
root-privileged capabilities to executables!
So what would be needed is code to set and get a special system xattr
(much like the POSIX ACL patches do) that is specifically set up for
capabilities, and with appropriate authorization access checks when
setting the capability xattr. In order to do that, we would have to
decide on the actual on-disk format encoding for capabilities (and one
which hopefully is extensible so that when additional capabilities are
added in the future, existing filesystems with capability attributes
remain backwards compatible). Finally, the ELF loader would have be
modified to read the capability extended attribute from the
executable, decode the xattr, and then set the capability masks
appropriately.
The code which I posted is a prerequisite for the above work, yes.
It's just that there's quite a bit of additional work that would be
necessary. (And this is all aside from the question about whether or
not it's a good idea for most system administrators to attempt to use
such a system once it was fully implemented.)
- Ted
On Thu, Oct 17, 2002 at 01:02:25PM +0200, Andreas Gruenbacher wrote:
> Filesystem capabilities move complexity out of applications into the
> file system (=system configuration), so the admins have to deal with
> an additional task.
>
> From a security point of view suid root applications that are
> dropping capabilities voluntarily aren't much different from plain
> old suid root apps; there may still be exploitable bugs before the
> code that drops capabilities (which doesn't mean that apps shouldn't
> drop capabilities). With capabilities the kernel ensures that
> applications cannot exceed their capabilities.
If developers drop capabilities they don't need as the very first
thing that the program does --- i.e., the first statement in main()
--- then it's done once, and it's no longer a configuration issue.
This is also better because the developer generally has a much better
idea what capabilities are needed by his/her program --- as compared
to having every single individual administrator have make this
determination by his or herself.
As far as bugs which might be there before the application drops root,
this is largely dealt with by dropping the capabilities as the very
first thing in main(). Now, you may say, what if the application
needs to do some processing work as root before they can drop some of
the capabilities? Well, in that case, if you have a buffer overrun or
other bug which might be exploitable before the capabilities are
dropped, even in a full capability system, the program is still
vulnerable in exactly the same way.
The one thing which you can't do by simply dropping the max effective
and current capabilities in a setuid root application, is to set a max
inheritable capability mask. That is, you do need to be more careful
if you have some number of capabilities raised, that they be
appropriately filtered or dropped before you exec another program.
But everything else can be done by dropping all the privileges you
don't need as the first thing in main.
> > So you claim, system administrators are stupid people?
Each additional thing which the system administrator has to do, is an
additional thing that he/she can *get* *wrong*. System administators
aren't stupid, just over-loaded, and often asked to administer
something that's too complicated.
Millions and millions of knobs and dials are not necessarily a good
thing. If there is basically only one correct answer for how the
knobs can be set up, sure, you can have a complex database for
applications to determine what sort of capability masks they should
have, and you can run that database against your database every night
(otherwise, you might miss someone quietly modifying one or two
capability masks to leave him/herself a back door).
But why go through all that effort? It may be a lot simpler to have
the application drop capabilities in main(), and then the standard MD5
integrity scan of your executable will do the job for you. Yes, it's
not perfect; but it's a heck of a lot easier to maintain.
Finally, it should also be noted that in order to get the full effect
of a capabilities system, you need to very tightly restrict the
inheritability capmask of all executables in the system. That is, if
/bin/cp isn't allowed to inherit the DAC override capability, then you
don't have to worry about a buffer overrun of a privileged executable
from calling /bin/cp to overwrite some critical system configuration
file. But by the same token, that means that a someone executing
/bin/cp from a root shell (or a root shell script) will also not be
able to override DAC. This is generally considered to be
unacceptable, so very often, most binaries in the system are given a
very high inheritable capmask, so that they can still be used with
privileges from a root shell. But as soon as you do that, you've
removed most of the advantages of a full-fledged capability system
over simply dropping capabilities in main().
So yes, a properly managed capability system can be more secure than
simpler alternatives. But it's a bear to manage, and would require
new userspace tools (which the administrator will probably not be
familiar, and at least initially would be far more immature than the
current standbys). Worst of all, in its fully secured form, is
extremely inconvenient for system administrators running out of a root
shell. (Basically, it no longer feels like Unix system
administration, but more like VMS system administration.) If you
don't do all of these things, a full-fledged capabilities system can
be much, much LESS secure.
- Ted
Theodore Ts'o wrote:
> > I saw capabilities and acl patches for ext2/3 enter -mm. Is it possible
> > now to give an executable (that lives on an ext2/ext3 fs) the necessary
> > rights to use SCHED_FIFO without being setuid root? Could someone give
> > me some pointers for these topics (capabilities support in linux, acl)?
> The patchs which I've been working on do not support capabilities;
> just extended attributes.
Ah, ok... I thought that things work like this: the capabilities support
already is in the kernel, and to give an app a particular capability,
one has to add a particalar extended attribute to the application
executable. So I'm wrong here it seems?
regards, Stefan
--
----> http://www.shockfrosted.org
GrandMasterLee <[email protected]> said:
> On Wed, 2002-10-16 at 22:26, Theodore Ts'o wrote:
[...]
> > Personally, I'm not so convinced that capabilities are such a great
> > idea. System administrators have a hard enough time keeping 12 bits
> > of permissions correct on executable files; with capabilities they
> > have to keep track of several hundred bits of capabilties flags, which
> > must be set precisely correctly, or the programs will either (a) fail
> > to function, or (b) have a gaping huge security hole.
Nodz.
> While working with LIDS in it's early stages of implementation, and
> having written some documentation around CAPs and extended attributes,
> as well as managing that environment, I see value in CAPs, but I see it
> a difficult task to say, manage 100 servers with very tight CAPs set.
It is easier on the sysadmin for the people upstream (developers,
distributors, ...) to set up stuff sanely in the executable. Sure, a lot of
flexibility is lost this way.
> > This probablem could be solved with some really scary, complex user
> > tools (which no one has written yet).
> Looking at CA Unicenter, they have an ACLs and CAPs product which does
> centralized management of those attributes to keep the configs sane
> across your environment. Not trying to advertise for them, but the point
> is, if a commercial product exists to do this, then it should be highly
> possible in the OSS community as well.
Sorry, but I gather the vast mayority of Linux instalations to be
single-machine (home use, ...). I have yet to see a hundred-machine setup
myself (maximal is some 30 around here), so this is out of the league of
most people anyway. Plus Linux is falling more and more into the hands of
the unwashed masses, who have a dificult time remembering not to do
everything as root (leave alone fix up permissions).
> > Alternatively you could just
> > let programs continue to be setuid root, but modify the executable to
> > explicitly drop all the capabilities except for the ones that are
> > actually needed as one of the first things that executable does.
>
> To make management easy for the admins when I dealt with LIDS and making
> it *very* tight, I had to write several wrappers, replace commands, etc
> so they ran chrooted automatically, etc. It was a PITA. Cool when it
> worked, but it was still a PITA.
But a once-in-the-development PITA, not a once-for-each-installation PITA
> > It perhaps only gives you 90% of the benefits of the full-fledged
> > capabilities model, but it's much more fool proof, and much easier to
> > administer.
> Perhaps exntending the security module to actually have a centralized
> host configuration utility, using say AES or diffie-hellman and SSL or
> SSH to do the configuration management of this. Centralizing, or
> distributing the management of this, but with a decided upon security
> architecture is what, imho, will actually make this type of
> configuration very useable, and manageable.
Have you seen any such centralized configuration management in real use?
The nearest we come here is Red Hat's kickstart for configuring the whole
Lab (mostly) the same when installing, and that is for only slightly
heterogeneous machines that must look the same to users.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Olaf Dietsche <olaf.dietsche#[email protected]> writes:
>So you claim, system administrators are stupid people?
Yes, definitely. There are lots of incredibly stupid admins out
there. There are some smart, some really smart, some smart-asses and
some paranoids but 99% of the people that call themselves "admins" are
unbelievably stupid. No matter how many different three-to-five letter
acronyms trail their names.
This is true for every OS out there. Look at the mess that the NT
rights management created... :-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
"Theodore Ts'o" <[email protected]> writes:
> On Thu, Oct 17, 2002 at 01:02:25PM +0200, Andreas Gruenbacher wrote:
>> With capabilities the kernel ensures that
>> applications cannot exceed their capabilities.
Which is a _big_ plus.
> as compared
> to having every single individual administrator have make this
> determination by his or herself.
I don't see this. It's a distribution issue. There will be
administrators, who want to do it on their own, but those will be a
minority.
> Each additional thing which the system administrator has to do, is an
> additional thing that he/she can *get* *wrong*. System administators
> aren't stupid, just over-loaded, and often asked to administer
> something that's too complicated.
Once the distributions have taken care of this, there's nothing too
complicated left.
> Millions and millions of knobs and dials are not necessarily a good
> thing. If there is basically only one correct answer for how the
> knobs can be set up, sure, you can have a complex database for
> applications to determine what sort of capability masks they should
> have, and you can run that database against your database every night
> (otherwise, you might miss someone quietly modifying one or two
> capability masks to leave him/herself a back door).
>
> But why go through all that effort?
Because it's easier, than patching millions and millions of programs?
Regards, Olaf.
On Thu, Oct 17, 2002 at 05:36:40PM +0200, Olaf Dietsche wrote:
> > as compared
> > to having every single individual administrator have make this
> > determination by his or herself.
>
> I don't see this. It's a distribution issue. There will be
> administrators, who want to do it on their own, but those will be a
> minority.
01/01/2007, The Register
"New capability hole in RedHat 12.0: 10 million users affected"
See my "capwrap" module:
http://arctrix.com/nas/linux/capwrap.tar.gz
To allow SCHED_FIFO you would need to give the process the CAP_SYS_NICE
capability. CAP_SYS_NICE is bit 23 (800000 in hex). Create a text file
with the following line and make it root suid:
&/usr/bin/someprogram 800000
If the capwrap module is loaded the kernel will recognize the file as a
"capability wrapper" and grant the specified capabilities to the
executable while running with the uid of the current user.
The capwrap module isn't fancy but is works and is simple. It doesn't
require any special filesystem. Since I'm no kernel hacker I don't know
if it's suitable for inclusion in the main tree. I would appreciate any
comments people have regarding it.
Neil
On Thu, 2002-10-17 at 08:22, Horst von Brand wrote:
> GrandMasterLee <[email protected]> said:
> > On Wed, 2002-10-16 at 22:26, Theodore Ts'o wrote:
>
> [...]
>
> > > Personally, I'm not so convinced that capabilities are such a great
> > > idea. System administrators have a hard enough time keeping 12 bits
> > > of permissions correct on executable files; with capabilities they
> > > have to keep track of several hundred bits of capabilties flags, which
> > > must be set precisely correctly, or the programs will either (a) fail
> > > to function, or (b) have a gaping huge security hole.
>
> Nodz.
>
> > While working with LIDS in it's early stages of implementation, and
> >...
>
> It is easier on the sysadmin for the people upstream (developers,
> distributors, ...) to set up stuff sanely in the executable. Sure, a lot of
> flexibility is lost this way.
I think the real perspective on this should be that lots of flexibility
can be lost this way, but not necessarily so that it inherently will be
lost. I say that because programming with the specification in mind that
flexibility should be as maintained as possible, while attempting to
provide the security in a sane and well thought out manner is a better
vehicle to acceptance. Thus people adopt things which are secure, but
flexible.
I respect the *BSD folks for taking a somewhat inverse approach to this
though, since a lot of flexibility is maintained while security is job
one.
> > > This probablem could be solved with some really scary, complex user
> > > tools (which no one has written yet).
>
> > Looking at CA Unicenter, they have an ACLs and CAPs product which does
> > centralized management of those attributes to keep the configs sane
> > across your environment. Not trying to advertise for them, but the point
> > is, if a commercial product exists to do this, then it should be highly
> > possible in the OSS community as well.
>
> Sorry, but I gather the vast mayority of Linux instalations to be
> single-machine (home use, ...). I have yet to see a hundred-machine setup
> myself (maximal is some 30 around here),
I have over 100 linux machines, which could benefit from this sort of
thing, which is why I mentioned CA eTrust's suite for this purpose. I
still have unanswered questions to this, but we'll probably give it a
trial run and see just what it really can/can't do. I'll be taking notes
of course to see what the OSS community can benefit from this
methodology.
> so this is out of the league of
> most people anyway. Plus Linux is falling more and more into the hands of
> the unwashed masses, who have a dificult time remembering not to do
> everything as root (leave alone fix up permissions).
I don't really agree about the unwashed masses bit, though I do
understand that viewpoint. To really open Linux to the world though, the
"unwashed masses" should be allowed to have input into something even if
they don't understand it fully. Their viewpoints and opinions will help
to fine tune some of the corner cases in the security area, and others
too.
All that aside, Linux in the enterprise is becoming *very* common. If
all goes well in our environment, we'll have several 2TB+ DBs in
production by this time next year.
> > > Alternatively you could just
> > > let programs continue to be setuid root....
>
> > To make management easy for the admins when I dealt with LIDS and making
> > it *very* tight, I had to write several wrappers, replace commands, etc
> > so they ran chrooted automatically, etc. It was a PITA. Cool when it
> > worked, but it was still a PITA.
>
> But a once-in-the-development PITA, not a once-for-each-installation PITA
That's not really what I was getting at. The problem is that I had to
make these things not a PITA for the admins, and it was a PITA, compared
to an "every day" system, to administer. In a sense all functionality
was there, but there were many more hoops to jump to do normal
administration. In a sense, it was re-learning how to administer 100
boxen, which just got more tedious.
The missing piece in this overall security architecture, to make things
more flexible, or semi-automated, was a distributed(or centralized)
state management system and repository for all ACLs and CAPs for all
users and the commands, filesystems, etc, affected. If there'd been
something like Kerberos on Steroids, thus supporting all ACLs and CAPs
in an authoritative way, it would've been much easier to configure and
maintain those configurations.
> > > It perhaps only gives you 90% of the benefits of the full-fledged
> > > capabilities model, but it's much more fool proof, and much easier to
> > > administer.
>
> > Perhaps exntending the security module to actually have a centralized
> > host configuration utility, using say AES or diffie-hellman and SSL or
> > SSH to do the configuration management of this. Centralizing, or
> > distributing the management of this, but with a decided upon security
> > architecture is what, imho, will actually make this type of
> > configuration very useable, and manageable.
>
> Have you seen any such centralized configuration management in real use?
Yes, as a matter of fact, we rolled our own, but it is still very basic,
though far more capable than just kickstart.
> The nearest we come here is Red Hat's kickstart for configuring the whole
> Lab (mostly) the same when installing, and that is for only slightly
> heterogeneous machines that must look the same to users.
Using something like System Imager, or the SystemInstaller suite from
IBM and Brian Finely, you can couple Kickstart with an image and then
version that image, with some custom programming around it, very easily.
You could, take it so far as to even use CVS or something similar, to
just keep track of changes in a cron'd manner just using a few scripts,
and have the images update as you please.
You should look at a combination of Kickstart, Current, and SI. I think
with a little work on top of all of those pieces, you could easily have
a free, kick ass configuration management system. (which btw, the SI
suite is becoming very good at that.)
The real point of all of this rhetoric though, is that CAPs are good,
ACLs are good, and extended attributes are good. It's just that darn
administrative bit that becomes a hassle in large environments.
--The GrandMaster
On Thu, Oct 17, 2002 at 08:12:13AM -0400, Theodore Ts'o wrote:
> On Thu, Oct 17, 2002 at 01:02:25PM +0200, Andreas Gruenbacher wrote:
> > Filesystem capabilities move complexity out of applications into the
> > file system (=system configuration), so the admins have to deal with
> > an additional task.
> >
> > From a security point of view suid root applications that are
> > dropping capabilities voluntarily aren't much different from plain
> > old suid root apps; there may still be exploitable bugs before the
> > code that drops capabilities (which doesn't mean that apps shouldn't
> > drop capabilities). With capabilities the kernel ensures that
> > applications cannot exceed their capabilities.
>
> If developers drop capabilities they don't need as the very first
> thing that the program does --- i.e., the first statement in main()
> --- then it's done once, and it's no longer a configuration issue.
I'm a C-programmer. I've looked at C++ a long time ago.
Turns out that my system also supports C++. I still don't care.
Turns out that C++ specifies that some code should be run before main
starts.
It seems that if I happen to link with a library that uses C++
internally, some code in that library can get run before my first
statement in main. Suddenly it IS my problem.
NOT GOOD.
If capabilities are correctly implemented, having "all" capabilities
will mean that it's equivalent to "setuid-root". Nothing worse than
what we have now. I can currently decide to take the setuid-ness of
mount away. I can currently decide to install a setuid bit on "lilo".
That is the flexibility of having it in the filesystem.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currenyly in such an *
* excursion: The stable situation does not include humans. ***************
Hi!
> > Ah, ok... I thought that things work like this: the capabilities support
> > already is in the kernel, and to give an app a particular capability,
> > one has to add a particalar extended attribute to the application
> > executable. So I'm wrong here it seems?
>
> First of all, you can't use a standard user extended attribute, since
> anyone with write access to the file will be allowed to set the
> extended attribute. This isn't good if you're going to be granting
What are extended attributes good for, then?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
Hi!
> See my "capwrap" module:
>
> http://arctrix.com/nas/linux/capwrap.tar.gz
>
> To allow SCHED_FIFO you would need to give the process the CAP_SYS_NICE
> capability. CAP_SYS_NICE is bit 23 (800000 in hex). Create a text file
> with the following line and make it root suid:
>
> &/usr/bin/someprogram 800000
>
> If the capwrap module is loaded the kernel will recognize the file as a
> "capability wrapper" and grant the specified capabilities to the
> executable while running with the uid of the current user.
>
> The capwrap module isn't fancy but is works and is simple. It doesn't
> require any special filesystem. Since I'm no kernel hacker I don't know
> if it's suitable for inclusion in the main tree. I would appreciate any
> comments people have regarding it.
I did similar thing using elf .note section... But this seems elegant
too. Perhaps you want to push it for inclusion?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
On Sunday 20 October 2002 16:16, Pavel Machek wrote:
> Hi!
>
> > > Ah, ok... I thought that things work like this: the capabilities
> > > support already is in the kernel, and to give an app a particular
> > > capability, one has to add a particalar extended attribute to the
> > > application executable. So I'm wrong here it seems?
> >
> > First of all, you can't use a standard user extended attribute, since
> > anyone with write access to the file will be allowed to set the
> > extended attribute. This isn't good if you're going to be granting
>
> What are extended attributes good for, then?
Extended attributes support different namespaces, like user.* and system.*.
The user.* namespace is treaded similarly to the file contents permission
wise, so users can associate attributes with files. Things like ACLs,
Capabilities, etc. are intended to be added to the system.* namespace. They
differ from user.* in that they require different permissions/capabilities
from the calling process.
ACLs are named system.posix_acl_access and system.posix_acl_default.
Capabilities could be named system.posix_caps, for example.
You can look this all up in the attr(5) manual page at
<http://acl.bestbits.at/cgi-man/attr.5>.
--Andreas.