I'm down to 8 undecided features: 6 removed and one I missed earlier.
http://www.kernel.org/pub/linux/kernel/people/rusty/2.6-not-in-yet
(Reproduced below.)
Removed ("vendor-driven" == "no", for purposes of the freeze)
Linux Trace Toolkit: "no"
statfs64: noone seems to be pushing
ext2/3 ACLs & EA: included
Crash Dumper: "no"
Hi-res Timers: "no"
SCSI and FibreChannel Hotswap: "via. maintainers but probably not"
Added:
Nanosecond Time Patch
Linus, are you going to appoint [davej] someone [davej] to help you
[davej] hold the freeze? It'd be nice if someone [davej] else had to
pre-approve or co-approve patches before they went in.
I don't really care who the somebody [davej] is.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Entrance criteria:
* Must have been submitted to lkml in the last month,
* Hasn't been rejected by the maintainer/Linus,
* Not appropriate for insertion during stable series (ie. too invasive, new feature, breaks userspace)
Key:
A: Author
M: lkml posting describing patch
D: Download URL
S: Size of patch, number of files altered (source/config), number of new files.
X: Impact summary (only parts of patch which alter existing source files, not config/make files)
T: Diffstat of whole patch
N: Random notes
In rough order of invasiveness (number of altered source files):
In-kernel Module Loader and Unified parameter support
A: Rusty Russell
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/
S: 841 kbytes, 290/48 files altered, 22 new
T: Diffstat
X: Summary patch (597k)
N: Requires new modutils
Nanosecond Time Patch
A: Andi Kleen
M: http://www.ussg.iu.edu/hypermail/linux/kernel/0210.3/0793.html
D: ftp://ftp.firstfloor.org/pub/ak/v2.5/nsec-2.5.44-2.bz2
S: 194 kbytes, 158/0 files altered, 0 new
T: Diffstat
X: Summary patch (181k)
N: The core of this patch is tiny: putting nanoseconds into filesystems is the bulk of this patch.
Fbdev Rewrite
A: James Simmons
M: http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.3/1267.html
D: http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
S: 2320 kbytes, 131/20 files altered, 40 new
T: Diffstat
X: Summary patch (401k)
ucLinux Patch (MMU-less support)
A: Greg Ungerer
M: http://lwn.net/Articles/11016/
D: http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.45-uc1.patch.gz
S: 2202 kbytes, 25/13 files altered, 427 new
T: Diffstat
X: Summary patch (43k)
N: Linus said looks good.
POSIX Timer API
A: George Anzinger
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103553654329827&w=2
D: http://unc.dl.sourceforge.net/sourceforge/high-res-timers/hrtimers-posix-2.5.45-1.0.patch
S: 66 kbytes, 18/1 files altered, 4 new
T: Diffstat
X: Summary patch (21k)
Hotplug CPU Removal Support
A: Rusty Russell
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Hotcpu/hotcpu-cpudown.patch.gz
S: 32 kbytes, 16/0 files altered, 0 new
T: Diffstat
X: Summary patch (29k)
initramfs
A: Al Viro / Jeff Garzik
M: http://www.cs.helsinki.fi/linux/linux-kernel/2001-30/0110.html
D: ftp://ftp.math.psu.edu/pub/viro/N0-initramfs-C21
S: 16 kbytes, 5/1 files altered, 2 new
T: Diffstat
X: Summary patch (5k)
N: Linus says he wants it.
Kernel Probes
A: Vamsi Krishna S
M: lists.insecure.org/linux-kernel/2002/Aug/1299.html
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Misc/kprobes.patch.gz
S: 18 kbytes, 3/3 files altered, 4 new
T: Diffstat
X: Summary patch (5k)
Rusty Russell wrote:
> Removed ("vendor-driven" == "no", for purposes of the freeze)
> Linux Trace Toolkit: "no"
I'm not sure exactly why this got a "no" this time around. For one thing,
LTT is certainly not "vendor-driven", I'm not getting paid a penny for
the work I'm putting in it ;)
In an earlier thread, Linus made the following statement with regards to LTT:
> I suspect we'll want to have some form of event tracing eventually, but
> I'm personally pretty convinced that it needs to be a per-CPU thing, and
> the core mechanism would need to be very lightweight. It's easier to build
> up complexity on top of a lightweight interface than it is to make a
> lightweight interface out of a heavy one.
At that time we didn't have the per-CPU buffering, but I promissed
Linus we would. And as promised we do have it now and the numbers we
have published have clearly demonstrated the tracer is lightweight. So
I was a bit suprised to see Linus come out and say:
> I don't know what this buys us.
Within that lengthy (ongoing) thread about "What's left over" he also
mentioned a few criteria for admitting new patches:
> In other words: the question is never EVER "Why shouldn't it be
> accepted?", but it is always "Why do we really not want to live
> without this?"
I've answered this one a few times for LTT already. We don't want to
live without this because we have no other way to:
> - Debug synchronization problems among processes (there is no other
> tool to do this, not gdb, not strace, not printf, ...)
> - Measure exact time spent wainting for kernel and which other
> processes a process had to wait for.
> - Measure exact time it takes for an interrupt's effects to propagate
> throughout the entire system.
> - Understand the exact behavior the system has to input. (what is
> the exact sequence of processes that run when I press a key).
> - Identify sporadic problems in very saturated systems. (thousands
> of servers and one of them is doing weird stuff).
> - etc.
Linus also added:
> There's a big "inertia" to features. It's often better to keep
> features _off_ the standard kernel if they may end up being
> further developed in totally new directions.
That's not really the case here. In fact, it's the complete inverse that
is happening with LTT: Because I'm spending so much time having to deal
with patch updates, I have much less time to work on the user-space
analysis tools. These analysis tools are the heart of the tracing system
and it is these tools that make LTT such a great utility, not the kernel
patch itself. All the kernel patch does is act as a dumb data collector.
It's the analysis tools that make sense of all this data and help the
user pinpoint his problem.
To the question "did you convince anyone else of including LTT in their
distro before trying the LKML?", my answer is: We didn't have to, they
included it without asking. Within 2 days of releasing the first version
of LTT in July 1999, I got an email from Zentropix (which would later be
acquired by Lineo) that they were going to include it in their distro. At
that time we only supported the i386 and the user tools were nowhere near
what they are at today. Today, LTT is included by the following
distributions: MontaVista, Lineo, Debian, ELinos, Denx, and (to the best of
my knowledge) UnitedLinux. Are we part of, say, RedHat? No we aren't, most
folks I've spoken to have said that the LTT patch is far too big for them
to maintain it independtly. I do, nevertheless, get many mails from users
who ask: "Do you have an LTT patch for RedHat XYZ?" Obviously I don't,
I simply can't generate an LTT patch for every distro out there.
"Why aren't any users of LTT being heard on the LKML?". Well they usually
never have a problem with the kernel itself. I do, however, get tons
of messages saying "do you have an LTT patch for version XYZ of the kernel?"
or "patch version XYZ doesn't compile properly on architecture A."
LTT users don't want to have to bother with the kernel, they want to get
the trace data out of the kernel and into the visualizer in order to be
able to debug their system. These guys aren't kernel developers, most of
them are common application developers who need to identify serious
problems having to do with the system's dynamic behavior. Which is exactly
what LTT is about.
We do see, nevertheless, many folks come to the LKML and ask a question
about being able to do a particular task with the Linux kernel and being
told, by other people than myself, "take a look at LTT."
Over the past 3.5 years of working on LTT I've had the chance to discuss
it with a few prominent kernel developers. I won't name any names, you
know who you are. Many of those folks have shown interest in LTT. Even
within the "what's left" thread folks came out and supported LTT's
inclusion. I have yet to be explained why users _don't_ want to be able
to debug their inter-process synchronization problems!?!
Can LTT continue to live outside of the kernel forever? Not without
slowing down the development of the analysis tools significantly.
Integrating the LTT patch into the kernel will certainly not mean the
end of development of LTT because the LTT patch in and of itself is
useless. The really interesting part is all in the user-space tools.
That's what makes LTT a very important tool for users. The more time
I have to put creating patch updates, the less time I have to actually
work on the user-space tools.
Have a look for yourself (if you haven't already):
http://www.opersys.com/LTT/
And if you'd prefer something that speaks for itself:
http://www.opersys.com/LTT/screenshots.html
FWIW, please add this patch back. We've been very open to LKML feedback
and have responded positively to the comments made by Ingo Molnar,
Linus Torvalds, Roman Zippel, Christoph Hellwing, Pavel Machek, and many
others. Either these people actually had lots of time to waste by going
over our work and actually making suggestions, which is doubtfull. Either
LTT is actually a tool that is worth taking an in-depth look at. I'll
let you draw your own conclusions.
Meanwhile, we're all ears in regards to potential omissions and suggested
changes.
Best regards,
Karim
===================================================
Karim Yaghmour
[email protected]
Embedded and Real-Time Linux Expert
===================================================
On Fri, 2002-11-01 at 01:49, Rusty Russell wrote:
> I'm down to 8 undecided features: 6 removed and one I missed earlier.
How about Olaf Dietsche's filesystem capabilities support? It has been
posted a couple times to LK, yesterday even.
We've had capabilities for ages (2.2?) but no filesystem support.
OpenBSD is recently bragging about no longer having any SUID root
binaries on the system.
With FS capabilities we (Linux) can have the same situation. Security
is a hot topic, and anything the kernel can do make security
better/easier seems worthy of consideration.
Dax Kelson
Dax Kelson wrote:
>
> On Fri, 2002-11-01 at 01:49, Rusty Russell wrote:
>> I'm down to 8 undecided features: 6 removed and one I missed earlier.
>
> How about Olaf Dietsche's filesystem capabilities support? It has been
> posted a couple times to LK, yesterday even.
>
>
> We've had capabilities for ages (2.2?) but no filesystem support.
>
> OpenBSD is recently bragging about no longer having any SUID root
> binaries on the system.
>
> With FS capabilities we (Linux) can have the same situation. Security
> is a hot topic, and anything the kernel can do make security
> better/easier seems worthy of consideration.
>
Unfortunately Alexander has spoken again:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103498212701476&w=4
You might want to check out some of the other reviews, I don't think people
gave it very high marks.
Cheers,
Nicholas
Dax Kelson <[email protected]> writes:
> On Fri, 2002-11-01 at 01:49, Rusty Russell wrote:
>> I'm down to 8 undecided features: 6 removed and one I missed earlier.
>
> How about Olaf Dietsche's filesystem capabilities support? It has been
> posted a couple times to LK, yesterday even.
Judging from the silence, I guess my mails take the direct route from
inbox to /dev/null ;-). But never mind, since the patch is very small,
it's easy for people to add fs capabilities themselves, if they're
interested.
> We've had capabilities for ages (2.2?) but no filesystem support.
#define _LINUX_CAPABILITY_VERSION 0x19980330 says, it's at least four
and a half years old.
> OpenBSD is recently bragging about no longer having any SUID root
> binaries on the system.
>
> With FS capabilities we (Linux) can have the same situation. Security
> is a hot topic, and anything the kernel can do make security
> better/easier seems worthy of consideration.
I think, it's not time for bragging yet, until fs capabilities get
quite a bit more testing.
Regards, Olaf.
Nicholas Wourms <[email protected]> writes:
> Unfortunately Alexander has spoken again:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103498212701476&w=4
Well, this was his first histerical response. In the meantime, all his
points have been addressed. I haven't heard of new objections, did you?
> You might want to check out some of the other reviews, I don't think people
> gave it very high marks.
I must have missed these. Unless you call promoting extended
attributes a review, of course.
Regards, Olaf.
On Fri, Nov 01, 2002 at 11:07:59PM +0100, Olaf Dietsche wrote:
> > Unfortunately Alexander has spoken again:
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=103498212701476&w=4
>
> Well, this was his first histerical response. In the meantime, all his
> points have been addressed. I haven't heard of new objections, did you?
I have several comments.
Where are the capabilities stored? In a file called .capability in the
root of the filesystem? Why would that root be writable, my current Coda
development tree has a read-only top-level directory in which different
realms can be dynamically mounted (similar to autofs).
How would I remove a capability from a vulnerable binary on readonly
media (i.e. cdrom), while still allowing other applications on the same
disk to run with special caps.
Right now an administrator can simply search for all setuid binaries to
check for possible 'unwanted priviledge elevations'. With the proposed
capabilities seemingly ordinary applications could suddenly have special
powers. Also when I explicitly drop capabilities secure a system, these
fs-caps could very well reintroduce a capability that were not in the
permitted set of any of the running processes.
It is probably better to remove than to add capabilities. As everyone
knows a setuid app is 'dangerous' use this code to remove some of the
power that normally is associated with setuid. I.e. when the setuid bit
is set for a specific application don't change euid to root, but still
give the power to bind to priviledged ports.
In the end I believe capabilities (like setuid) should be a local
decision. Yes, I'm looking at this from the viewpoint of a distributed
network filesystem that crosses administrative boundaries, and as such I
don't always trust whatever is stored in a mounted volume.
Why not modify a program like sudo or super that can give capabilities
to processes based on local rules and configuration... Ok there already
is a programs that does something like this which is called 'whichcap'.
Another solution is to have a trusted daemon that is the only process
in the system with the capability to grant capabilities to other
proceses. Other processes can send a request to this daemon, which can
consult local rules, double check md5 checksum or whatever paranoia is
needed before it actually does a setcap.
Jan
In message <1036175565.2260.20.camel@mentor> you write:
>
> On Fri, 2002-11-01 at 01:49, Rusty Russell wrote:
> > I'm down to 8 undecided features: 6 removed and one I missed earlier.
>
> How about Olaf Dietsche's filesystem capabilities support? It has been
> posted a couple times to LK, yesterday even.
Hmmm... cutting it pretty fine 8)
I'm not sure how much it buys us in real life, but that's not my
decision.
Added,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
In message <[email protected]> you write:
>
> Rusty Russell wrote:
> > Removed ("vendor-driven" == "no", for purposes of the freeze)
> > Linux Trace Toolkit: "no"
>
> I'm not sure exactly why this got a "no" this time around.
"I don't know what this buys us" == "no" AFAICT.
You might surprise me, but it looks like Linus wants more trusted
developers to come running to him going "LTT is really cool, we need
it for XXX". Of *course* you think it's great, otherwise you wouldn't
work on it.
> For one thing, LTT is certainly not "vendor-driven", I'm not getting
> paid a penny for the work I'm putting in it ;)
You misunderstand. When Linus says "vendor-driven" he means what
usually happens is that vendors pick it up then the users come back
and convince Linus that it's worth including.
> That's not really the case here. In fact, it's the complete inverse that
> is happening with LTT: Because I'm spending so much time having to deal
> with patch updates, I have much less time to work on the user-space
> analysis tools.
Hey, I feel your pain. Really: the module rewrite has the same issue,
except I doubt a vendor would pick it up since it breaks compatibility
with standard userspace, and they have enough to worry about.
I've put your patch back in, but I expect Linus will say "Rusty you
fucking idiot, I already said "no" once."
Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Key:
A: Author
M: lkml posting describing patch
D: Download URL
S: Size of patch, number of files altered (source/config), number of new files.
X: Impact summary (only parts of patch which alter existing source files, not config/make files)
T: Diffstat of whole patch
N: Random notes
In rough order of invasiveness (number of altered source files):
In-kernel Module Loader and Unified parameter support
A: Rusty Russell
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Module/
S: 859 kbytes, 296/44 files altered, 24 new
T: Diffstat
X: Summary patch (609k)
N: Requires new modutils
Nanosecond Time Patch
A: Andi Kleen
M: http://www.ussg.iu.edu/hypermail/linux/kernel/0210.3/0793.html
D: ftp://ftp.firstfloor.org/pub/ak/v2.5/nsec-2.5.44-2.bz2
S: 194 kbytes, 158/0 files altered, 0 new
T: Diffstat
X: Summary patch (181k)
N: The core is tiny: putting nanoseconds into filesystems is the bulk of this patch.
Fbdev Rewrite
A: James Simmons
M: http://www.uwsg.iu.edu/hypermail/linux/kernel/0111.3/1267.html
D: http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
S: 2320 kbytes, 131/20 files altered, 40 new
T: Diffstat
X: Summary patch (401k)
Linux Trace Toolkit (LTT)
A: Karim Yaghmour
M: http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0832.html
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103491640202541&w=2
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103423004321305&w=2
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103247532007850&w=2
D: http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.45-vanilla-021030-2.2.bz2
S: 257 kbytes, 68/3 files altered, 9 new
T: Diffstat
X: Summary patch (92k)
statfs64
A: Peter Chubb
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103610918825614&w=2
D: http://marc.theaimsgroup.com/?l=linux-kernel&m=103610918825614&w=2
S: 48 kbytes, 53/0 files altered, 2 new
T: Diffstat
X: Summary patch (32k)
POSIX Timer API
A: George Anzinger
M: http://marc.theaimsgroup.com/?l=linux-kernel&m=103553654329827&w=2
D: http://unc.dl.sourceforge.net/sourceforge/high-res-timers/hrtimers-posix-2.5.45-1.0.patch
S: 66 kbytes, 18/1 files altered, 4 new
T: Diffstat
X: Summary patch (21k)
Hotplug CPU Removal Support
A: Rusty Russell
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Hotcpu/hotcpu-cpudown.patch.gz
S: 32 kbytes, 16/0 files altered, 0 new
T: Diffstat
X: Summary patch (29k)
initramfs
A: Al Viro / Jeff Garzik
M: http://www.cs.helsinki.fi/linux/linux-kernel/2001-30/0110.html
D: ftp://ftp.math.psu.edu/pub/viro/N0-initramfs-C21
S: 16 kbytes, 5/1 files altered, 2 new
T: Diffstat
X: Summary patch (5k)
N: Linus says he wants it.
Kernel Probes
A: Vamsi Krishna S
M: lists.insecure.org/linux-kernel/2002/Aug/1299.html
D: http://www.kernel.org/pub/linux/kernel/people/rusty/patches/Misc/kprobes.patch.gz
S: 18 kbytes, 3/3 files altered, 4 new
T: Diffstat
X: Summary patch (5k)
On Fri, Nov 01, 2002 at 11:32:43AM -0700, Dax Kelson wrote:
>
> On Fri, 2002-11-01 at 01:49, Rusty Russell wrote:
> > I'm down to 8 undecided features: 6 removed and one I missed earlier.
>
> How about Olaf Dietsche's filesystem capabilities support? It has been
> posted a couple times to LK, yesterday even.
Ugh. Personally, as I've said, I'm not convinced filesystem
capabilities is worth it, providing the illusion of security --- and
probably will make most systems more insecure because most system
administrators won't be able to deal with fs capabilties competently.
HOWEVER, if we're going to do it, Olaf's patches is really not the way
to do it. If we're going to do it at all, the right way to do it is
via extended attributes. Using a sparse file to store capabilities
indexed by inode numbers is a bad idea; it will break if the user uses
resize2fs on an ext2/3 filesystem, for example.
- Ted
Rusty Russell <[email protected]> writes:
> In message <1036175565.2260.20.camel@mentor> you write:
>>
>> How about Olaf Dietsche's filesystem capabilities support? It has been
>> posted a couple times to LK, yesterday even.
>
> Hmmm... cutting it pretty fine 8)
I don't understand this. What do you mean with that?
> I'm not sure how much it buys us in real life, but that's not my
> decision.
I'm not sure how much iptables buy us in real life, but that's not my
decision either. There are people - at least me ;-) - who are
convinced, that fs capabilities are another piece in the security
puzzle.
Regards, Olaf.
"Theodore Ts'o" <[email protected]> writes:
> Ugh. Personally, as I've said, I'm not convinced filesystem
> capabilities is worth it, providing the illusion of security --- and
Like ACL? SCNR :-)
> probably will make most systems more insecure because most system
> administrators won't be able to deal with fs capabilties competently.
I still don't get it. How is this different from suid root. The worst
I can imagine is an admin doing chcap all+eip, which is no different
from doing a chown root; chmod u+s.
> HOWEVER, if we're going to do it, Olaf's patches is really not the way
> to do it. If we're going to do it at all, the right way to do it is
> via extended attributes. Using a sparse file to store capabilities
> indexed by inode numbers is a bad idea; it will break if the user uses
> resize2fs on an ext2/3 filesystem, for example.
Dragging yet another one out of you. This is a pretty strong argument
against my implementation. Any other hints?
Regards, Olaf.
On Sat, 2 Nov 2002, Theodore Ts'o wrote:
>
> HOWEVER, if we're going to do it, Olaf's patches is really not the way
> to do it. If we're going to do it at all, the right way to do it is
> via extended attributes. Using a sparse file to store capabilities
> indexed by inode numbers is a bad idea; it will break if the user uses
> resize2fs on an ext2/3 filesystem, for example.
Clearly inode numbers are a bad way to handle it, but I don't think inode
attributes are that great either. I would personally prefer directory
entry attributes, so that the same file can show up with different
behaviour in different places.
I think it was a mistake to have permissions be part of the inode in the
first place, but that's UNIX for you. A direntry-based approach is _so_
much more flexible, and doesn't really have any downsides.
(Having attributes in the direntry also makes it possible to much more
efficiently scan directories for types of files without having to look up
the inode information).
We can't fix the UNIX permission issue, but if we _do_ make FS
capabilities available, I will personally cast a strong vote for not
hiding the information in the inode.
There are two fairly trivial ways to do it:
- put the actual data in the directory entry itself. This is efficient,
but not very easily extensible, since most directory structures have
serious size limitations.
- Make a new file type, and put just that information in the directory
(so that it shows up in d_type on a readdir()). Put the real data in
the file, ie make it largely look like an "extended symlink".
The latter approach is probably a bit too reminiscent of a Windows
"shortcut" aka LNK file to some people, but hey, maybe it's a good idea.
Linus
On Sat, 2002-11-02 at 00:06, Theodore Ts'o wrote:
> On Fri, Nov 01, 2002 at 11:32:43AM -0700, Dax Kelson wrote:
> >
> > On Fri, 2002-11-01 at 01:49, Rusty Russell wrote:
> > > I'm down to 8 undecided features: 6 removed and one I missed earlier.
> >
> > How about Olaf Dietsche's filesystem capabilities support? It has been
> > posted a couple times to LK, yesterday even.
>
> Ugh. Personally, as I've said, I'm not convinced filesystem
> capabilities is worth it, providing the illusion of security --- and
> probably will make most systems more insecure because most system
> administrators won't be able to deal with fs capabilties competently.
I see this as a "vendor, RPM maintainer, developer" thing. The
developer,vendor,RPM mainter should be able to determine exactly what
capabilities an otherwise SUID root app needs and ship it appropriately.
Most sysadmin can't 'deal with X', where X is:
- Setup routing properly
- Configure kerberos
- Compile a kernel
- Use setfactl
- ext2/3 attributes
- IPTables
- SGID directories
- Apply a patch
That doesn't mean we should remove the above because they can be used
incorrectly/inappropriately and possibly damage and/or insecure a
system.
Dax
Olaf Dietsche <olaf.dietsche#[email protected]> writes:
> "Theodore Ts'o" <[email protected]> writes:
>
>> HOWEVER, if we're going to do it, Olaf's patches is really not the way
>> to do it. If we're going to do it at all, the right way to do it is
>> via extended attributes. Using a sparse file to store capabilities
>> indexed by inode numbers is a bad idea; it will break if the user uses
>> resize2fs on an ext2/3 filesystem, for example.
>
> Dragging yet another one out of you. This is a pretty strong argument
> against my implementation. Any other hints?
With dumping capabilities before resize and restoring them afterwards,
you can solve this. See:
<http://home.t-online.de/home/olaf.dietsche/linux/capability/dumpcaps.pl>
Regards, Olaf.
In article <[email protected]> you wrote:
> I still don't get it. How is this different from suid root. The worst
> I can imagine is an admin doing chcap all+eip, which is no different
> from doing a chown root; chmod u+s.
The probvlem is that most software does not know abaout capabilities. A
simple example is libc which will not ignore LD_PRELOAD because it does not
notice that there is a difference in effective and real capabilities of the
proces.
Personally I think this is solvable, and we realy need a way to enable
admins to use the least priveledge principle on their servers by removing
suid root programs completely.
Greetings
Bernd
--
http://www.freefire.org
In article <[email protected]> you wrote:
> I think it was a mistake to have permissions be part of the inode in the
> first place, but that's UNIX for you. A direntry-based approach is _so_
> much more flexible, and doesn't really have any downsides.
The main downside is the problem, that an object then can have multiple
different permissions and there is no easy way to ensure a basic level:
a- the kernel can't drop priveledges on a modified object easyly (this would
require your attribution to contain a version or checksumed reference)
b- the user can't drop/restrict a object once he knows that it's data is now
more sensitive (he has to worry about all old hard and softlinks to the
file)
c- how do you handle renames or moves of the data instances? move the
associated permissions of the moved entry and let all others point to nil
like breakign symlinks?
Greetings
Bernd
On Sat, Nov 02, 2002 at 10:47:07AM -0800, Linus Torvalds wrote:
> - Make a new file type, and put just that information in the
> directory (so that it shows up in d_type on a readdir()). Put the
> real data in the file, ie make it largely look like an "extended
> symlink".
reading directories therefore causes lots of seeks and performance
begins to suck again
IMO, extended attributes are a better place to store this and making
it per-inode, there is an argument that having a file behave
differently in different places is unecessaryly complex and really
doesn't solve any know real-world problems
--cw
On Sat, 2 Nov 2002, Linus Torvalds wrote:
> Clearly inode numbers are a bad way to handle it, but I don't think
> inode attributes are that great either. I would personally prefer
> directory entry attributes, so that the same file can show up with
> different behaviour in different places.
I'm sure we can come up with even more confusing behaviour
if we want, but it'll take some serious creativity.
Sure it's more flexible, but I wonder how many userland
programs will be broken if we change the permission model
and how well users can protect their data this way.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Sat, 2 Nov 2002, Rik van Riel wrote:
>
> Sure it's more flexible, but I wonder how many userland
> programs will be broken if we change the permission model
> and how well users can protect their data this way.
This is not a "change". Existing behaviour clearly cannot change. We're
talking about new interfaces to export capabilities in the filesystem.
And pathnames are a _hell_ of a lot better and straightforward interface
than inode numbers are. It's confusing when you change the permission on
one path to notice that another path magically changed too.
Linus
I have to wonder, just how many setuid executables do people have?
Implementing filesystem capability bits in ramfs or tmpfs might do
the job. At boot, initramfs stuff puts a few trusted executables
in /trusted and sets the capability bits. Then "mount --bind" to
put /trusted/su over an empty /bin/su file, or use symlinks.
One might as well make "nosuid" the default then, and mount the
root filesystem that way. It's not as if a system needs to have
gigabytes of setuid executables.
On Sat, 2 Nov 2002, Linus Torvalds wrote:
> On Sat, 2 Nov 2002, Rik van Riel wrote:
> >
> > Sure it's more flexible, but I wonder how many userland
> > programs will be broken if we change the permission model
> > and how well users can protect their data this way.
>
> This is not a "change". Existing behaviour clearly cannot change. We're
> talking about new interfaces to export capabilities in the filesystem.
>
> And pathnames are a _hell_ of a lot better and straightforward interface
> than inode numbers are. It's confusing when you change the permission on
> one path to notice that another path magically changed too.
It's also going to be confusing when you change permissions on
an inode and the extended attributes in one of the paths to the
inode don't change with it.
It'd be confusing as hell if I did a 'chmod go-r' on a file I
own, but have others continue reading the file because of some
extended attributes giving them the rights to do so.
Or am I misunderstanding the kinds of extended attributes you
want to have determined by pathname instead of by inode ?
It'd be nice to have an overview of exactly which permissions
and attributes are per file and which are per pathname ;)
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Sat, 2 Nov 2002, Linus Torvalds wrote:
>
> On Sat, 2 Nov 2002, Rik van Riel wrote:
> >
> > Sure it's more flexible, but I wonder how many userland
> > programs will be broken if we change the permission model
> > and how well users can protect their data this way.
>
> This is not a "change". Existing behaviour clearly cannot change. We're
> talking about new interfaces to export capabilities in the filesystem.
>
> And pathnames are a _hell_ of a lot better and straightforward interface
> than inode numbers are. It's confusing when you change the permission on
> one path to notice that another path magically changed too.
It's equally confusing to find out that link(2) doesn't preserve
file properties.
Frankly, I'm less than sure that ability to raise capabilities is
a good thing - being able to drop them is certainly nice, but I doubt
that partial suid-root will be better than full suid-root and it
certainly makes security model even more complex. And incomplete
understanding of security model is a great recipe for PITA - demonstrated
way too many times already...
Folks, seriously - it might be very tempting to add features in that
area, but more features actually increase overall security. Just look
at the track record of systems with baroque security models and ask
yourself whether we want to go there.
Linus Torvalds <[email protected]> writes:
> - Make a new file type, and put just that information in the directory
> (so that it shows up in d_type on a readdir()). Put the real data in
> the file, ie make it largely look like an "extended symlink".
How would you go from a regular file to the new extended symlink?
Regards, Olaf.
On Sat, 2 Nov 2002, Alexander Viro wrote:
> Folks, seriously - it might be very tempting to add features in that
> area, but more features actually increase overall security. Just look
Arrgh. s/increase/decrease/, obviously
Linus Torvalds wrote:
>
> And pathnames are a _hell_ of a lot better and straightforward interface
> than inode numbers are. It's confusing when you change the permission on
> one path to notice that another path magically changed too.
Would this not allow a user to add permissions to a file, by creating a
new directory entry and linking it to an existing inode?
Would that not be a greater security hole?
On Sun, 2002-11-03 at 00:22, Linus Torvalds wrote:
>
> On Sat, 2 Nov 2002, Rik van Riel wrote:
> >
> > Sure it's more flexible, but I wonder how many userland
> > programs will be broken if we change the permission model
> > and how well users can protect their data this way.
>
> This is not a "change". Existing behaviour clearly cannot change. We're
> talking about new interfaces to export capabilities in the filesystem.
So you are talking about a new interface that sucks. Slight difference
in situation no difference in result. At the point where link/rename and
even NFS happenings on remote boxes may get involved I don't want to go
anywhere near it. One thing Unix actually got right from the beginning
is that rights belong to objects not to names. Name based labelling has
never worked in or out of computing.
What you are suggesting is the equivalent of marking documents 'secret'
by putting them in a specific drawer and hoping nobody ever misfiles it.
Everyone instead writes "secret" on the document - guess why
On Sat, 2 Nov 2002, Rik van Riel wrote:
>
> Or am I misunderstanding the kinds of extended attributes you
> want to have determined by pathname instead of by inode ?
Look at the subject line.
Linus
On Sun, 3 Nov 2002, Olaf Dietsche wrote:
> Linus Torvalds <[email protected]> writes:
>
> > - Make a new file type, and put just that information in the directory
> > (so that it shows up in d_type on a readdir()). Put the real data in
> > the file, ie make it largely look like an "extended symlink".
>
> How would you go from a regular file to the new extended symlink?
I don't understand the question.
Let's say that you have a binary like /usr/bin/sendmail, and you want to
give it a certain set of capabilities (ie you want to _avoid_ making it
suid root - you only want to give it the specific capability of being able
to chown files to others and whatever else it is sendmail really wants to
do).
So I'd suggest _not_ attaching that capability to the sendmail binary
itself, or to any inode number of that binary. A binary is a binary is a
binary - it's just the data. Instead, I'd attach the information to the
directory entry, either directly (ie the directory entry really has an
extra field that lists the capabilities) or indirectly (ie the directory
entry is really just an "extended symlink" that contains not just the path
to the binary, but also the capabilities associated with it).
The reason I like directory entries as opposed to inodes is that if you
work this way, you can actually give different people _different_
capabilities for the same program. You don't need to have two different
installs, you can have one install and two different links to it.
Linus
On Sat, 2 Nov 2002, David D. Hagood wrote:
> Linus Torvalds wrote:
> >
> > And pathnames are a _hell_ of a lot better and straightforward interface
> > than inode numbers are. It's confusing when you change the permission on
> > one path to notice that another path magically changed too.
>
> Would this not allow a user to add permissions to a file, by creating a
> new directory entry and linking it to an existing inode?
>
> Would that not be a greater security hole?
No. The file itself has _no_ capabilities at all. If you just link to it,
you can give it whatever capabilities _you_ have as a user (well, normal
users don't really have any capabilities to give, but you get the idea).
Linus
On Sat, 2 Nov 2002, Linus Torvalds wrote:
> The reason I like directory entries as opposed to inodes is that if you
> work this way, you can actually give different people _different_
> capabilities for the same program. You don't need to have two different
> installs, you can have one install and two different links to it.
<shrug> that can be done without doing anything to filesystem.
Namely, turn current "nosuid" of vfsmount into a mask of capabilities.
Then use bindings instead of links. *Note* - binary _is_ marked suid,
mask tells which capabilities _not_ to gain. It's OK - attempt to
link(2) to the thing using binding will see that oldname and newname
are within different vfsmounts, so instead of link to suid-root binary
you get -EXDEV.
And that works on any fs, can be made per-user and can be _seen_
by admin - bindings are visible in /proc/mounts (yes, I remember that
we need to fix the crap with pathnames).
I can do that thing in a weekend - it's trivial to implement.
No need to bugger filesystems for that.
Alan Cox wrote:
> anywhere near it. One thing Unix actually got right from the beginning
> is that rights belong to objects not to names. Name based labelling has
> never worked in or out of computing.
I think the most important aspects are always that the concept is
understandable, doesn't make the users to jump through hoops, and
doesn't violate the principle of least surprise too often.
> What you are suggesting is the equivalent of marking documents 'secret'
> by putting them in a specific drawer and hoping nobody ever misfiles it.
> Everyone instead writes "secret" on the document - guess why
This happens if you have a design that is based on taking away
privileges/rights/capabilities/power/whatever. If the "naked"
object has no special powers, misfiling it does no damage at all.
Of course, you want to make sure nothing else can be slipped into
that magic drawer. Just imagine somebody takes the GPL from The
Drawer of World Domination, and puts the Windows EULA there :-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
On Sat, Nov 02, 2002 at 07:31:08PM -0500, Albert D. Cahalan wrote:
> I have to wonder, just how many setuid executables do people have?
i've run perfectly sane webservers with suid only on /bin/su. a few
errors are spat out, but things tend to work. in all honesty i'm yet to
see many other uses for it in a server-admin'd-by-small-group-of-people
situation, except perhaps for sendmail.
al's idea with the mount flags did perk up the old ears though, i would
like to see this done.
j.
--
toyota power: http://indigoid.net/
On Sat, 2 Nov 2002, Alexander Viro wrote:
>
> <shrug> that can be done without doing anything to filesystem.
> Namely, turn current "nosuid" of vfsmount into a mask of capabilities.
> Then use bindings instead of links.
I like that idea. It's very explicit, and clearly name-based, and we do
have 99% of the support for it already.
Linus
On Sat, 2 Nov 2002, Linus Torvalds wrote:
>
> On Sat, 2 Nov 2002, Alexander Viro wrote:
> >
> > <shrug> that can be done without doing anything to filesystem.
> > Namely, turn current "nosuid" of vfsmount into a mask of capabilities.
> > Then use bindings instead of links.
>
> I like that idea. It's very explicit, and clearly name-based, and we do
> have 99% of the support for it already.
It occurs to me that we actually do have the "extended symlink" concept in
UNIX already: the existing "#!" escape for executables is really exactly
that. It's just a structured symlink, except the extension is not a
capability, but rather it's the script to be fed to the executable.
With a simple extended binfmt_misc.c or binfmt_script.c, we could do a
capability escape (that only removes capabilities, but allows for suid
shells) fairly easily if people really want it. And it would work on any
almost-UNIXy filesystem, including NFS etc.
But I like Al's idea of mount binds even more, although it requires maybe
a bit more administration.
Linus
The principle of least privilege says that instead of a system full of
binaries running as root, we should have a system of binaries running as
non-root with only the capabilities they need.
The typical break-in involves gaining non-root access first, then doing a
privilege escalation attack to gain root. A system using capabilities
makes the escalation attack must more difficult.
How are we currently doing? The following (pathetically short list of)
binaries use capabilities:
vsftpd
ntptimeset
ntpdate
ntpd
named
What are the potential users of capabilities?
47 SUID root binaries (EVERYTHING install of Red Hat Linux 8.0)
Filesystem capabilities support could take care of these SUID root
binaries. Historically, SUID root binaries have been heavily used in
privilege escalation attacks.
How about daemons that are launched as root? These could be potential
users of capabilities + drop root right now.
There is a snag though. When non-root binaries (eg, daemons running as
non-root but with capabilities) execve(), all capabilities are cleared, so
if some of these daemons need to exec other binaries with certain
capabilities, it currently won't work.
"ps aux | grep root" to take a look. We see stuff like:
syslogd
cardmgr
apmd
smartd
xinetd
dhclient
gpm
crond
cupsd
anacron
rhnsd
login
mingetty
X
This is not an exhaustive list. The system I checked was not running many
daemons.
In summary, there is lots that could be done today to secure daemons. The
clearing of capabilities on exec by non-root binaries needs be addressed
(I posted a patch in May 2002). File system capabilities support can
fix the large amount of SUID root binaries that exist. OpenBSD 3.2
(just released) has started to implement a similar technique to get rid
of SUID root binaries.
Once filesystem capabilities is added to the kernel, RPM and DPKG should
be fixed so that, otherwise SUID root binaries, can be installed with
capabilities support automatically.
This should be the vendors / package maintainers job. The average sysadmin
should get the benefits without having to think about it.
Dax Kelson
On Sat, Nov 02, 2002 at 07:23:11PM -0800, Linus Torvalds wrote:
>
> On Sat, 2 Nov 2002, Alexander Viro wrote:
> >
> > <shrug> that can be done without doing anything to filesystem.
> > Namely, turn current "nosuid" of vfsmount into a mask of capabilities.
> > Then use bindings instead of links.
>
> I like that idea. It's very explicit, and clearly name-based, and we do
> have 99% of the support for it already.
Bindings are cool, but once you start talking about doing a lot of
them, they're rather ungainly due to not actually being persisted on
the filesystem, no?
A better approach is to just make a user-space capabilities-wrapper
that's setuid, drops capabilities quickly and safely and calls the
real app. Something like:
# mv ping ping.real
# chmod -s ping.real
# mkcapwrap +net_raw ping.real
# chmod +s ping
# showcapwrap ping
invokes /bin/ping
grants net_raw
#
No fs magic, no persistence issues, all user-space.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On Sat, 2 Nov 2002, Oliver Xymoron wrote:
> # mv ping ping.real
> # chmod -s ping.real
> # mkcapwrap +net_raw ping.real
> # chmod +s ping
> # showcapwrap ping
> invokes /bin/ping
> grants net_raw
> #
Do you mean?
# mv ping ping.real
# chmod -s ping.real
# mkcapwrap +net_raw ping
# chmod +s ping
# showcapwrap ping
invokes /bin/ping.real
grants net_raw
#
The wrapper needs to setuid/gid to the uid/gid that invokes it.
uid root with no caps (or few caps) is still very powerful (replace
binaries owned by root, read /etc/shadow, etc).
Currently all capabilities are cleared when non-root app does a execp.
This would need to be addressed.
Dax
On Sat, 2 Nov 2002, Alexander Viro wrote:
> <shrug> that can be done without doing anything to filesystem.
> Namely, turn current "nosuid" of vfsmount into a mask of capabilities.
> Then use bindings instead of links. *Note* - binary _is_ marked suid,
> mask tells which capabilities _not_ to gain. It's OK - attempt to
> link(2) to the thing using binding will see that oldname and newname
> are within different vfsmounts, so instead of link to suid-root binary
> you get -EXDEV.
Any thoughts on how /usr/bin/(rpm|dpkg) copes with setting up the binding
when installing a package?
Dax
On Sat, 2 Nov 2002, Dax Kelson wrote:
> On Sat, 2 Nov 2002, Alexander Viro wrote:
>
> > <shrug> that can be done without doing anything to filesystem.
> > Namely, turn current "nosuid" of vfsmount into a mask of capabilities.
> > Then use bindings instead of links. *Note* - binary _is_ marked suid,
> > mask tells which capabilities _not_ to gain. It's OK - attempt to
> > link(2) to the thing using binding will see that oldname and newname
> > are within different vfsmounts, so instead of link to suid-root binary
> > you get -EXDEV.
>
> Any thoughts on how /usr/bin/(rpm|dpkg) copes with setting up the binding
> when installing a package?
<shrug> for example, /etc/init.d/foo-bindings.sh and update-rc.d invoked
in post-install. Hell knows what RPM equivalent is, but there definitely
is one...
On Sat, Nov 02, 2002 at 09:00:38PM -0700, Dax Kelson wrote:
> On Sat, 2 Nov 2002, Oliver Xymoron wrote:
>
> > # mkcapwrap +net_raw ping.real
>
> Do you mean?
>
> # mkcapwrap +net_raw ping
Actually I meant:
# mkcapwrap +net_raw ping.real ping
..in keeping with ln(1).
> The wrapper needs to setuid/gid to the uid/gid that invokes it.
Generally, though there'd need to be an option to emulate, say, setgid
mail.
> Currently all capabilities are cleared when non-root app does a execp.
> This would need to be addressed.
Hrmm. I thought the inherit mask dealt with that.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On Sat, 2 Nov 2002, Oliver Xymoron wrote:
>
> Bindings are cool, but once you start talking about doing a lot of
> them, they're rather ungainly due to not actually being persisted on
> the filesystem, no?
Well, they _are_ persistent in the filesystem, although in this case "the
filesystem" is /etc/fstab.
It's not that different from the ".capabilities" file, except it's a lot
more explicit, and from an implementation standpoint it's a lot easier.
However, I think there is a problem with Al's original approach: the bind
can _not_ be just a mask that takes away capabilities from a suid
application, since that would imply that the app has to be marked suid in
the first place (and accessing it _without_ going through the bind will
give it elevated privileges, which is what we're trying to avoid).
So the bind would have to _add_ capabilities, not take them away.
That's not really a problem, and the advantage of the filesystem bind
approach is that it is extremely explicit, and it is trivial for a
maintainer to at all times see all such "elevated" binaries: as Al points
out, the only thing you need to do is to just ask to be shown the mount
list with "mount" or with "cat /proc/mounts".
> A better approach is to just make a user-space capabilities-wrapper
> that's setuid, drops capabilities quickly and safely and calls the
> real app.
This is _not_ a good approach from a sysadmin standpoint. The sysadmin
does not explicitly know what the suid binary does internally, the
sysadmin just sees a number of suid binaries and has to trust them.
Yes, I realize that your example had "showcapwrap" etc sysadmin tools to
work around this, and make the wrapping be transparent to the sysadmin.
That certainly works, although it still depends on trusting that the
wrapping cannot be confused some way. I guess that could be done fairly
easily (although I think you'd want to make "mkcapwrap" actually _sign_
the wrapped binaries, to make sure that nobody can later try to inject a
"bad" binary that _looks_ ok to "showcapwrap" and fools the admin to think
everything is ok).
But from a security maintenance standpoint, wouldn't it be _nice_ to be
able to
- do a complete "find" over the whole system to show that there is not a
single suid binary anywhere.
- trivially show each and every binary that is allowed elevated
permissions (and _which_ elevated permissions) by just doing a "mount".
- and since the mount trees are really per-process, you can allow certain
process groups to have mounts that others don't have.
I think that as a anal-retentive security admin, I'd like such a system.
Linus
On Sat, 2 Nov 2002, Linus Torvalds wrote:
> But I like Al's idea of mount binds even more, although it requires maybe
> a bit more administration.
OK, will do - will be fun to take a break from drivers/* and devfs excrements
I'm digging in...
BTW, here's a fresh demonstration (found half an hour ago) that capabilities
do *not* permit more lax attitude when writing stuff with elevated priveleges:
* /usr/lib/games/nethack/recover is run at the boot time (as root)
to recover crashed games.
* Debian nethack 3.4.0-3.1 has it installed root.games and it
is group-writable - cretinism in debian/rules, upstream is not guilty
in that (BTW, so is /usr/lib/games/nethack/recover-helper).
* ergo, any exploitable hole in sgid-games binary (rogue, for
instance) is trivially elevated to root exploit.
Capabilities will *not* help that one - suid-games binaries need
to be able to write as 'games', that's the whole reason why they are
suid-games. Normally they use it to create save files. And quite a
few of them are ripe with exploits - c.f. recent rogue(6) holes.
Normally that would lead only to ability to screw others' save
files (and potentially to compromise their accounts, if corrupted save
file can trigger a hole in another game). Besides, many of these beasts
are old and didn't get too much attention.
Now, combined with packaging fuckup (which is a nice prototype of
ACL fuckups to come) we get a lovely path leading to root exploit. Bugger
all, one *still* has to think when writing code. A shame, isn't it?
On Sat, 2 Nov 2002, Linus Torvalds wrote:
> However, I think there is a problem with Al's original approach: the bind
> can _not_ be just a mask that takes away capabilities from a suid
> application, since that would imply that the app has to be marked suid in
> the first place (and accessing it _without_ going through the bind will
> give it elevated privileges, which is what we're trying to avoid).
No, that's OK -
mount --bind /usr/bin/foo.real /usr/bin/foo.real
mount -o remount,nosuid /usr/bin/foo.real
or equivalent couple of mount(2) calls will do the trick nicely (and that,
BTW, we have right now - you can selectively disable/enable suid on files
and entire subtrees).
On Sat, 2 Nov 2002, Alexander Viro wrote:
>
> No, that's OK -
>
> mount --bind /usr/bin/foo.real /usr/bin/foo.real
> mount -o remount,nosuid /usr/bin/foo.real
Ehh. With the nosuid mount that will remove the effectiveness of the suid
bit (not just the user change - it will also mask off the elevation of the
capabilities), so the bind-mount with the capability mask will now mask
off nothing to start with.
Wouldn't it be much nicer to have:
/usr/bin/foo - no suid bits, no capabilities by default
mount --bind --capability=xx,yy /usr/bin/foo /usr/bin/foo
where the mount actually adds capabilities? Looks more understandable to
me.
Linus
On Sat, Nov 02, 2002 at 08:20:44PM -0800, Linus Torvalds wrote:
>
> On Sat, 2 Nov 2002, Oliver Xymoron wrote:
> >
> > Bindings are cool, but once you start talking about doing a lot of
> > them, they're rather ungainly due to not actually being persisted on
> > the filesystem, no?
>
> Well, they _are_ persistent in the filesystem, although in this case "the
> filesystem" is /etc/fstab.
Yes, but this has annoying side effects like booting single-user and
discovering things like /sbin/ping doesn't exist because mount -a
didn't run yet. Stuff like that sucks.
> That's not really a problem, and the advantage of the filesystem bind
> approach is that it is extremely explicit, and it is trivial for a
> maintainer to at all times see all such "elevated" binaries: as Al points
> out, the only thing you need to do is to just ask to be shown the mount
> list with "mount" or with "cat /proc/mounts".
But they show up as regular files to things like ls. And magically
break when copied, moved, etc.. Backups and bind mounts? It's not
obvious to me how that works.
> > A better approach is to just make a user-space capabilities-wrapper
> > that's setuid, drops capabilities quickly and safely and calls the
> > real app.
>
> This is _not_ a good approach from a sysadmin standpoint. The sysadmin
> does not explicitly know what the suid binary does internally, the
> sysadmin just sees a number of suid binaries and has to trust them.
It's not perfect. Perhaps there's some #! script-like way to do it
where there's only one binary to trust. One more point in its favor is
it works in 2.4...
> Yes, I realize that your example had "showcapwrap" etc sysadmin tools to
> work around this, and make the wrapping be transparent to the sysadmin.
> That certainly works, although it still depends on trusting that the
> wrapping cannot be confused some way. I guess that could be done fairly
> easily (although I think you'd want to make "mkcapwrap" actually _sign_
> the wrapped binaries, to make sure that nobody can later try to inject a
> "bad" binary that _looks_ ok to "showcapwrap" and fools the admin to think
> everything is ok).
>
> But from a security maintenance standpoint, wouldn't it be _nice_ to be
> able to
>
> - do a complete "find" over the whole system to show that there is not a
> single suid binary anywhere.
That's just show.
> - trivially show each and every binary that is allowed elevated
> permissions (and _which_ elevated permissions) by just doing a "mount".
That might not strike _you_ as weird, but then this is the same guy
who wanted files you could cd into..
> - and since the mount trees are really per-process, you can allow certain
> process groups to have mounts that others don't have.
You can do that with any capability scheme.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
On Sat, 2 Nov 2002, Linus Torvalds wrote:
>
> On Sat, 2 Nov 2002, Alexander Viro wrote:
> >
> > No, that's OK -
> >
> > mount --bind /usr/bin/foo.real /usr/bin/foo.real
> > mount -o remount,nosuid /usr/bin/foo.real
>
> Ehh. With the nosuid mount that will remove the effectiveness of the suid
> bit (not just the user change - it will also mask off the elevation of the
> capabilities), so the bind-mount with the capability mask will now mask
> off nothing to start with.
Nope. Look - ->i_mode is still the same, nothing had changed. Suid
interpretation happens *not* on a superblock level. What happens is
* we look at file->f_dentry->d_inode->i_mode. No suid bit - no love.
* then we look at file->f_vfsmnt->mnt_flags. If that has MNT_NOSUID -
no love, again.
* if suid bit is present and vfsmount is not marked nosuid - there
we go.
In other words, nosuid status is _already_ per-binding - having a nosuid
binding at /usr/bin/foo.real doesn't have anything to do with suid (or
partial suid) bindings elsewhere.
So trick above will remove effectiveness of the suid bit for binding
at the place where real binary lives. If you want that place to retain
some capabilities - s/nosuid/capmask=.../ in the above. It has nothing
to do with other places where you might bind the same file - each binding
has its own vfsmount and thus its own ->mnt_flags...
On Sat, 2002-11-02 at 22:03, Oliver Xymoron wrote:
>
> Yes, but this has annoying side effects like booting single-user and
> discovering things like /sbin/ping doesn't exist because mount -a
> didn't run yet. Stuff like that sucks.
No. Because in single user mode, you are root.
Dax
On Sat Nov 02, 2002 at 09:04:07PM -0700, Dax Kelson wrote:
> On Sat, 2 Nov 2002, Alexander Viro wrote:
>
> > <shrug> that can be done without doing anything to filesystem.
> > Namely, turn current "nosuid" of vfsmount into a mask of capabilities.
> > Then use bindings instead of links. *Note* - binary _is_ marked suid,
> > mask tells which capabilities _not_ to gain. It's OK - attempt to
> > link(2) to the thing using binding will see that oldname and newname
> > are within different vfsmounts, so instead of link to suid-root binary
> > you get -EXDEV.
>
> Any thoughts on how /usr/bin/(rpm|dpkg) copes with setting up the binding
> when installing a package?
postint script
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Sat Nov 02, 2002 at 10:37:48PM -0700, Dax Kelson wrote:
> On Sat, 2002-11-02 at 22:31, Erik Andersen wrote:
> > On Sat Nov 02, 2002 at 09:04:07PM -0700, Dax Kelson wrote:
> > >
> > >
> > > Any thoughts on how /usr/bin/(rpm|dpkg) copes with setting up the binding
> > > when installing a package?
> >
> > postint script
>
> Sure, but editing /etc/fstab from postint is messy, potentially
> dangerous, and could possibly collide with someone doing a manual edit
> of /etc/fstab.
>
> Maybe we need a /etc/fstab.d/ directory and teach /bin/mount about it.
Or have an /etc/fstab.d/ directory plus have an update-fstab
script that collates the entries in that directory and stuffs the
result into /etc/fstab, and have update-fstab called from the postint
script.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Sat, 2002-11-02 at 22:31, Erik Andersen wrote:
> On Sat Nov 02, 2002 at 09:04:07PM -0700, Dax Kelson wrote:
> >
> >
> > Any thoughts on how /usr/bin/(rpm|dpkg) copes with setting up the binding
> > when installing a package?
>
> postint script
Sure, but editing /etc/fstab from postint is messy, potentially
dangerous, and could possibly collide with someone doing a manual edit
of /etc/fstab.
Maybe we need a /etc/fstab.d/ directory and teach /bin/mount about it.
On Sun, 3 Nov 2002, Alexander Viro wrote:
>
> If you want that place to retain some capabilities -
> s/nosuid/capmask=.../ in the above.
Ok, I get your example, but nope, I don't think it will work.
Why? Because then the suid check will work, and not only will you get all
capabilities (_if_ the suid was root), you will also have changed your ID
(since that was how you got enough capabilities to be able to mask them
off).
Which you do _not_ want to do. You just want the capabilities, you don't
necessarily want to run as somebody else (or if you do, that "somebody
else" might well be "nobody"). So suid vs capabilities are different: you
may even want them to be complementary.
In other words, it would actually make perfect sense to have
-r-sr-sr-x 1 nobody mail 451280 Apr 8 2002 /usr/bin/sendmail
mount --bind --capability=chown,bindlow /usr/bin/sendmail /usr/bin/sendmail
ie have it be suid nobody:mail (to _remove_ any vestige of normal user
rights but give it write permission on the mail directory), and then
separately giving it specific capabilities to allow it to chown files it
creates and bind to port 25).
(yeah, maybe that's a bad example, I dunno what sendmail actually wants to
do).
In the above, the suid'ness of the binary is totally independent of the
capabilities: the suid bits don't have any meaning for the capability set,
since it's not about root, but the suid bits _do_ have meaning from a
filesystem permission standpoint.
Linus
On Sat, 2 Nov 2002, Oliver Xymoron wrote:
>
> Yes, but this has annoying side effects like booting single-user and
> discovering things like /sbin/ping doesn't exist because mount -a
> didn't run yet.
No, /sbin/ping _would_ exist, it just wouldn't have gotten the elevated
capabilities yet.
But that shouldn't matter in single-user mode, since it doesn't _need_ any
elevated capabilities (unless you've somehow made your single-user mode
run as a normal user - that's really secure, but you can't do anything
with it ;)
[ In general the schenario you bring up is actually a good thing: a
failure mode would fail with _less_ provileges rather than more. Which
on the whole is exactly what you want - failure to initialize something
should not leave nasty security holes around. ]
On the other hand, I have this suspicion that the most secure setup is one
that the sysadmin is _used_ to, and knows all the pitfalls of. Which
obviously is a big argument for just maintaining the status quo with suid
binaries.
We have decades of knowledge on how to minimize the negative impact of
suid (I've used sendmail as an example of a suid program, and yet last I
looked sendmail was actually pretty careful about dropping all unnecessary
privileges very early on).
And as Al points out, new security features don't mean that you can just
stop being careful.
Linus
On Sat, 2002-11-02 at 22:42, Erik Andersen wrote:
> On Sat Nov 02, 2002 at 10:37:48PM -0700, Dax Kelson wrote:
> > On Sat, 2002-11-02 at 22:31, Erik Andersen wrote:
> > > On Sat Nov 02, 2002 at 09:04:07PM -0700, Dax Kelson wrote:
> > > >
> > > >
> > > > Any thoughts on how /usr/bin/(rpm|dpkg) copes with setting up the binding
> > > > when installing a package?
> > >
> > > postint script
> >
> > Sure, but editing /etc/fstab from postint is messy, potentially
> > dangerous, and could possibly collide with someone doing a manual edit
> > of /etc/fstab.
> >
> > Maybe we need a /etc/fstab.d/ directory and teach /bin/mount about it.
>
> Or have an /etc/fstab.d/ directory plus have an update-fstab
> script that collates the entries in that directory and stuffs the
> result into /etc/fstab, and have update-fstab called from the postint
> script.
I would forget about the update-fstab script. Why merge?
There is lots of precedent for the .d/ directories in /etc. These
directories are mostly for the benefit of packages, and they have no
update-foo scripts.
/etc/crontab & /etc/cron.(hourly|daily|weekly|monthly)/ & /etc/cron.d/
/etc/logrotate.conf & /etc/logrotate.d/
/etc/profile & /etc/profile.d/
/etc/httpd/conf/httpd.conf & /etc/httpd/conf.d/
/etc/xinetd.conf & /etc/xinetd.d/
/etc/lvmtab & /etc/lvmtab.d/
/etc/makedev.d/
/etc/pam.d/
On Sat, 2 Nov 2002, Linus Torvalds wrote:
> Why? Because then the suid check will work, and not only will you get all
> capabilities (_if_ the suid was root), you will also have changed your ID
> (since that was how you got enough capabilities to be able to mask them
> off).
Umm... As for getting all capabilities, I was planning to do the following:
modify suid check to give you everything except the mask taken from vfsmount.
So that's no problem - this is exactly the place I would modify.
> Which you do _not_ want to do. You just want the capabilities, you don't
> necessarily want to run as somebody else (or if you do, that "somebody
> else" might well be "nobody"). So suid vs capabilities are different: you
> may even want them to be complementary.
Now, _that_ may be more serious. However...
> In other words, it would actually make perfect sense to have
>
> -r-sr-sr-x 1 nobody mail 451280 Apr 8 2002 /usr/bin/sendmail
>
> mount --bind --capability=chown,bindlow /usr/bin/sendmail /usr/bin/sendmail
*blam*
Congratulations with potential crapload of security holes - now anyone
who'd compromised a process running as nobody can chmod the damn thing
and modify it.
And that is the reason why suid-nonroot is bad. It creates a class of
binaries that can easily give you a root compromise if one of them has
an exploit - even if that one is never run by root. That is the reason
why such things are done with sgid-nonroot and not with suid. Member of
group can't chmod. Owner can. And yes, you can take away chmod - but
you need to do that for everything that will run with that UID. Which
might be impossible - some might need chmod(2).
FWIW,
$ ls -l /usr/sbin/sendmail
-rwxr-sr-x 1 root smmsp 617672 Oct 2 13:33 /usr/sbin/sendmail
- no suid at all. And making it suid-nobody would decrease security.
Note that _all_ binaries that need any capabilities now are written to
be suid-root. So the only case left from your scenario is
* new binary
* runs with UID of caller
* wants some capabilities
* doesn't want to be portable (it won't work on any other Unix,
since we had assumed that it doesn't want to be suid-root and still
relies on caps present)
* doesn't use any of $BIGNUM portable mechanisms (separate
helpers, descriptor-passing, yadda, yadda).
Umm... Do we really want to help these out? We don't even have an
excuse of that being an important 3rd-party program brought from some
other system - it will be Linux-only and new, at that.
Now, _removal_ of capabilities on exec makes a whole lot of sense -
suid or not. So IMO correct way to look at the stuff that adds them
as suid-root slighlty mitigated by removal of some things.
I can do addition of capabilities via the same mechanism - it's trivial.
But I really doubt that we want it as first-class thing.
Comments?
On Sat, 2 Nov 2002, Linus Torvalds wrote:
> On the other hand, I have this suspicion that the most secure setup is one
> that the sysadmin is _used_ to, and knows all the pitfalls of. Which
> obviously is a big argument for just maintaining the status quo with suid
> binaries.
>
> We have decades of knowledge on how to minimize the negative impact of
> suid (I've used sendmail as an example of a suid program, and yet last I
> looked sendmail was actually pretty careful about dropping all unnecessary
> privileges very early on).
Quite so. Now, ability to _remove_ capabilities on exec() is a Good Thing(tm)
regardless of suid. It can be combined with suid - that gives you something
that is still evil, but less than it used to be. But I don't see any point
in new independent mechanism for raising caps - e.g. since it assumes a
bunch of new programs that were written to run with elevated caps and
with assumption that they will be less dangerous than suid-root ones.
Somehow, it doesn't make me happy about running such programs - not for
first 5 years or so.
On Sat, 2002-11-02 at 23:37, Alexander Viro wrote:
>
> Congratulations with potential crapload of security holes - now anyone
> who'd compromised a process running as nobody can chmod the damn thing
> and modify it.
Speaking of user 'nobody', modern best practices (and shipped vendor
configuration) strongly discourages lumping everything under 'nobody'.
Each app should run in its own security context by itself. That is why
I have all the following users in my /etc/passwd:
apache nscd squid xfs ident rpc pcap nfsnobody radvd gdm named ntp
I didn't have to do this myself, my vendor shipped it that way. I don't
have any daemons running as 'nobody'.
I think it is well understood that having more than one app run as the
same uid (historically, nobody) is a Bad Thing(tm).
> And that is the reason why suid-nonroot is bad.
Generally speaking yes, but don't remove that ability for those who have
applications/circumstances where suid-noroot+caps can be a simple and
clean solution. Vendors, of course, are not likely to ship
suid-noroot+caps binaries.
> Note that _all_ binaries that need any capabilities now are written to
> be suid-root. So the only case left from your scenario is
> * new binary
> * runs with UID of caller
> * wants some capabilities
> * doesn't want to be portable (it won't work on any other Unix,
> since we had assumed that it doesn't want to be suid-root and still
> relies on caps present)
> * doesn't use any of $BIGNUM portable mechanisms (separate
> helpers, descriptor-passing, yadda, yadda).
>
> Umm... Do we really want to help these out? We don't even have an
> excuse of that being an important 3rd-party program brought from some
> other system - it will be Linux-only and new, at that.
Pardon if I miss parsed.
On a 'everything install RHL8.0', there exists 47 SUID root binaries.
Don't we want to convert them to 'run with UID of caller and with some
capabilities'?
Isn't this the common case?
A process executing as root, even with ZERO capabilities, is still quite
privileged/dangerous. That process can replace root owned binaries, and
read /etc/shadow.
I see two problem spaces that capabilities helps with:
1. SUID root binaries --> run as caller with need capabilities
2. root daemons --> run as defined non-root user with capabilities
Problem space 2 can be tackled right now assuming the daemon doesn't try
to fork+exec another binary and expect that binary to inherit the
capabilities that it has.
>
> Comments?
See above :)
A call from left field:
As a sys-admin I love the idea of the capabilities, but I hate this mount
--bind thing. I'd really rather see it have its own command name. If it were
strictly something that happens at mount time for a filesystem that'd be one
thing, but
>mount --bind --capability=xx,yy /usr/bin/foo /usr/bin/foo
looks like a mistake.
If you were loop mounting the binary into the user's directory, then I could
see using mount.
This would be clearer:
setcap -c xx,yy /usr/bin/foo
(I also have nothing against long option names.)
--
The end is a finish, a conclusion or a completion.
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
On 3 Nov 2002, Dax Kelson wrote:
> Each app should run in its own security context by itself. That is why
> I have all the following users in my /etc/passwd:
>
> apache nscd squid xfs ident rpc pcap nfsnobody radvd gdm named ntp
>
> I didn't have to do this myself, my vendor shipped it that way. I don't
> have any daemons running as 'nobody'.
>
> I think it is well understood that having more than one app run as the
> same uid (historically, nobody) is a Bad Thing(tm).
Yes, but there is more to that. Namely, these daemons acquire their UIDs
not via suid bit and they are very likely owned by some other UID (root,
most likely).
> On a 'everything install RHL8.0', there exists 47 SUID root binaries.
>
> Don't we want to convert them to 'run with UID of caller and with some
> capabilities'?
>
> Isn't this the common case?
> 1. SUID root binaries --> run as caller with need capabilities
> 2. root daemons --> run as defined non-root user with capabilities
>
> Problem space 2 can be tackled right now assuming the daemon doesn't try
> to fork+exec another binary and expect that binary to inherit the
> capabilities that it has.
3. suid-root that needs full-caps (check and you'll see quite a few of these.
just at random - sudo, chfn, mount). These are equivalent to root - either
by function (if su can't give me root, I'll be _really_ PO'd) or by trivial
elevation of priveleges available if they are subverted (are capable of
changing the file that contains, among other things, shell of UID 0, are
capable of calling mount(2), which is enough for everything).
4. can be modified in a way that wouldn't require suid or would _really_
require it for a small helper (i.e. there is a small piece that is
root-equivalent, but it can be separated).
5. gratitious.
Care to give a splitup into these categories? And yes, (4) requires
modification of programs - TANSTAAFL and all such...
As for (2) - most of those are started by priveleged process, so they
need to drop capabilities more than acquire them. What exactly do
you have in mind?
[email protected] (Hacksaw) wrote on 03.11.02 in <[email protected]>:
> As a sys-admin I love the idea of the capabilities, but I hate this mount
> --bind thing. I'd really rather see it have its own command name. If it were
> strictly something that happens at mount time for a filesystem that'd be one
> thing, but
>
> >mount --bind --capability=xx,yy /usr/bin/foo /usr/bin/foo
>
> looks like a mistake.
>
> If you were loop mounting the binary into the user's directory, then I could
> see using mount.
>
> This would be clearer:
>
> setcap -c xx,yy /usr/bin/foo
>
> (I also have nothing against long option names.)
As a sysadmin, this should be about 20 seconds with your favourite editor
to create a "setcap" shell script.
MfG Kai
>As a sysadmin, this should be about 20 seconds with your favourite editor
>to create a "setcap" shell script.
Ville Herva pointed out that it'd be modifying in core structures, so maybe it
is the right thing to do. I do like the idea of every setuid file needing to
be listed in one place.
I still find "mount --bind --capability=xx,yy /usr/bin/foo /usr/bin/foo" to be
a strange syntax. It implies that one is mounting /usr/bin/foo over
/usr/bin/foo, and adding the xx,yy capabilities.
--
What we hear is the way that we hear.
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
On Sun, 2002-11-03 at 02:43, Werner Almesberger wrote:
> > What you are suggesting is the equivalent of marking documents 'secret'
> > by putting them in a specific drawer and hoping nobody ever misfiles it.
> > Everyone instead writes "secret" on the document - guess why
>
> This happens if you have a design that is based on taking away
> privileges/rights/capabilities/power/whatever. If the "naked"
> object has no special powers, misfiling it does no damage at all.
That isnt actually true. When you misfile it you mistakenly give it
powers. An untrusted document stuck in the secret drawer becomes seen to
have much higher value. It might for example lead the military to
believe a project is secret, make a decision on that basis and get
everyone shot because the opponents knew about it.
Alan
On Sun, 2002-11-03 at 02:03, Linus Torvalds wrote:
> So I'd suggest _not_ attaching that capability to the sendmail binary
> itself, or to any inode number of that binary. A binary is a binary is a
> binary - it's just the data. Instead, I'd attach the information to the
> directory entry, either directly (ie the directory entry really has an
> extra field that lists the capabilities) or indirectly (ie the directory
> entry is really just an "extended symlink" that contains not just the path
> to the binary, but also the capabilities associated with it).
So what are the semantics for writing to the file. If I modify a setuid
(or setpartlysetuid) type file then I wan't the setuidness revoked as
happens now. That is done for very good reason. Your system appears to
need a scan of the entire file system to find directory references to
this object, done atomically.
> The reason I like directory entries as opposed to inodes is that if you
> work this way, you can actually give different people _different_
> capabilities for the same program. You don't need to have two different
> installs, you can have one install and two different links to it.
I'll trade 500K of disk space for a working security model especially as
the case in question is not that common.
Alan
On Sun, 2002-11-03 at 04:20, Linus Torvalds wrote:
> - do a complete "find" over the whole system to show that there is not a
> single suid binary anywhere.
Thats a hard problem. Since your scan is non atomic and because you have
directory notifications a running processes can have the setuid apps can
move the setuid bits around the file system to hide from you.
> - trivially show each and every binary that is allowed elevated
> permissions (and _which_ elevated permissions) by just doing a "mount".
>
> - and since the mount trees are really per-process, you can allow certain
> process groups to have mounts that others don't have.
>
> I think that as a anal-retentive security admin, I'd like such a system.
Being able to give process trees a file system view which has certain
capability raising properties removed is basically the existing
capability mechanism but with a cleaner interface and more powerful
semantics.
Doing that with just mount properties and using them to revoke rights
works for me. There is a vfs corner case (clearly the setuid bit of a
file that isnt setuid from this namespace point of view) which is very
very important but not hard to get right.
On Sun, 2002-11-03 at 03:35, Linus Torvalds wrote:
> With a simple extended binfmt_misc.c or binfmt_script.c, we could do a
> capability escape (that only removes capabilities, but allows for suid
> shells) fairly easily if people really want it. And it would work on any
> almost-UNIXy filesystem, including NFS etc.
>
> But I like Al's idea of mount binds even more, although it requires maybe
> a bit more administration.
The two are seperate things IMHO
Namespaces is a way to inherit revocation of rights on a large scale (or
a small one true). #! is a way to handle program specific revocation of
rights which _is_ filesystem persistent.
The former is a database view, the latter is an actual database change
On Sun, 2002-11-03 at 06:46, Alexander Viro wrote:
> Quite so. Now, ability to _remove_ capabilities on exec() is a Good Thing(tm)
> regardless of suid. It can be combined with suid - that gives you something
> that is still evil, but less than it used to be. But I don't see any point
> in new independent mechanism for raising caps - e.g. since it assumes a
> bunch of new programs that were written to run with elevated caps and
> with assumption that they will be less dangerous than suid-root ones.
> Somehow, it doesn't make me happy about running such programs - not for
> first 5 years or so.
Removing capabilities is an easy thing to add. Firstly the binary can do
it anyway even on 2.4, secondly you can add an ELF property easily
enough which says which capabilities this gets if it is marked setuid
On Sun, 2002-11-03 at 04:28, Alexander Viro wrote:
> BTW, here's a fresh demonstration (found half an hour ago) that capabilities
> do *not* permit more lax attitude when writing stuff with elevated priveleges:
> * /usr/lib/games/nethack/recover is run at the boot time (as root)
> to recover crashed games.
> * Debian nethack 3.4.0-3.1 has it installed root.games and it
> is group-writable - cretinism in debian/rules, upstream is not guilty
> in that (BTW, so is /usr/lib/games/nethack/recover-helper).
> * ergo, any exploitable hole in sgid-games binary (rogue, for
> instance) is trivially elevated to root exploit.
This is why you also want something stronger than just capability
models. In a strong security system the following happens.
User hacks nethack
Users compromises recover (and in doing so reduces its integrity)
Reboot
Root tries to run recover
Recover has insufficient integrity
Error messages appear
You would also have a "game playing" role which would mean a compromised
game could only write to the game score and save files, and could only
read the nominated game configuration files.
The problem with this is its nontrivial to set up all the rules. Being
able to use namespaces to revoke rights is a big help. If we were to add
a capability for 'getting out of chroot' then we can also combine it
with chroot to drop users into an unpriviledged universe from which they
cannot escape because we took away the chroot stuff and we took away
rawio and so on
Alan
Linus Torvalds <[email protected]> writes:
> On Sun, 3 Nov 2002, Olaf Dietsche wrote:
>
>> Linus Torvalds <[email protected]> writes:
>>
>> > - Make a new file type, and put just that information in the directory
>> > (so that it shows up in d_type on a readdir()). Put the real data in
>> > the file, ie make it largely look like an "extended symlink".
>>
>> How would you go from a regular file to the new extended symlink?
>
> So I'd suggest _not_ attaching that capability to the sendmail binary
> itself, or to any inode number of that binary. A binary is a binary is a
> binary - it's just the data. Instead, I'd attach the information to the
> directory entry, either directly (ie the directory entry really has an
> extra field that lists the capabilities) or indirectly (ie the directory
> entry is really just an "extended symlink" that contains not just the path
> to the binary, but also the capabilities associated with it).
Now I understand. It's a combined symlink/capabilities pair. I thought
to have this extra direntry, containing capabilities only. But I
didn't get the connection between the binary and the cap direntry. You
go just the other way round from cap/symlink to the binary.
> The reason I like directory entries as opposed to inodes is that if you
> work this way, you can actually give different people _different_
> capabilities for the same program. You don't need to have two different
> installs, you can have one install and two different links to it.
I thought that's what the inheritable vs. permitted set is for.
Regards, Olaf.
Linus Torvalds <[email protected]> writes:
> On the other hand, I have this suspicion that the most secure setup is one
> that the sysadmin is _used_ to, and knows all the pitfalls of. Which
> obviously is a big argument for just maintaining the status quo with suid
> binaries.
As is shown every now and then, when the next security hole is
reported. So we stay at the lowest common denominator.
I've always had good experience with educating people, not with
dumbing them down. But maybe I've been just lucky then and worked
with very smart people.
> We have decades of knowledge on how to minimize the negative impact of
> suid (I've used sendmail as an example of a suid program, and yet last I
> looked sendmail was actually pretty careful about dropping all unnecessary
> privileges very early on).
So we throw out the baby with the bath water. This is conservatism at
it's worst.
> And as Al points out, new security features don't mean that you can just
> stop being careful.
Stating the obvious. Capabilities are not an end in itself, nor is suid
root. It's just another line of defense to help with these binaries,
which are _not_ capability aware.
Regards, Olaf.
Oliver Xymoron <[email protected]> writes:
> Generally, though there'd need to be an option to emulate, say, setgid
> mail.
Look at sucap and execcap available with libcap. Combine them and you
get a capability wrapper.
> On Sat, Nov 02, 2002 at 09:00:38PM -0700, Dax Kelson wrote:
>
>> Currently all capabilities are cleared when non-root app does a execp.
>> This would need to be addressed.
>
> Hrmm. I thought the inherit mask dealt with that.
You need the inherit set of the parent process _and_ the inherit set
of the binary to agree. For the latter you need some sort of fs
capabilities.
Regards, Olaf.
Linus Torvalds <[email protected]> writes:
> On Sat, 2 Nov 2002, David D. Hagood wrote:
>> Linus Torvalds wrote:
>>
>> Would this not allow a user to add permissions to a file, by creating a
>> new directory entry and linking it to an existing inode?
>>
>> Would that not be a greater security hole?
>
> No. The file itself has _no_ capabilities at all. If you just link to it,
> you can give it whatever capabilities _you_ have as a user (well, normal
> users don't really have any capabilities to give, but you get the idea).
So, this would be the inheritable set only.
Regards, Olaf.
Dax Kelson <[email protected]> writes:
> This should be the vendors / package maintainers job. The average sysadmin
> should get the benefits without having to think about it.
Thanks for pointing this out. Most people seem to forget or ignore
this.
Regards, Olaf.
Linus Torvalds <[email protected]> writes:
> On Sat, 2 Nov 2002, Linus Torvalds wrote:
>
> It occurs to me that we actually do have the "extended symlink" concept in
> UNIX already: the existing "#!" escape for executables is really exactly
> that. It's just a structured symlink, except the extension is not a
> capability, but rather it's the script to be fed to the executable.
>
> With a simple extended binfmt_misc.c or binfmt_script.c, we could do a
> capability escape (that only removes capabilities, but allows for suid
> shells) fairly easily if people really want it. And it would work on any
> almost-UNIXy filesystem, including NFS etc.
Look at <http://marc.theaimsgroup.com/?l=linux-kernel&m=101639590421603>.
Regards, Olaf.
On Sun, 3 Nov 2002, Olaf Dietsche wrote:
> > And as Al points out, new security features don't mean that you can just
> > stop being careful.
>
> Stating the obvious. Capabilities are not an end in itself, nor is suid
> root. It's just another line of defense to help with these binaries,
> which are _not_ capability aware.
Bullshit. To _be_ careful you need to understand the implications of
what you are doing. To do so in a more complicated model is harder,
not easier.
See Linus' suggestion regarding sendmail upthread - thing that looked
like improvement of security (hey, we can make it never retain any
traces of original UID, that should be good) had actually made thing
more vulnerable.
More features != better security. Quite often it's exact opposite.
Human do make errors, otherwise suid-root stuff wouldn't be a problem
to start with. And when security mechanism increases probability
of error it becomes a menace.
Odds of getting screwed are 0 if programs contain no bugs. We are dealing
with real world and there are non-zero odds of exploitable holes being there
and getting found. What we want is to decrease the odds of compromise,
right? So how are ACLs/capabilities/etc. settings different from program
internals? Either can contain bugs. Neither is guaranteed to be done
correctly. Odds of compromise depend on odds of bugs in both. Yet you
seem to imply that metadata *will* be set correctly. By the same vendors
that had shipped vulnerable binary in the first place. Even though the
complexity of metadata had grown.
Please, get real. "Completely understood" is much more important than
"versatile" when it comes to security models. And as for additional lines
of defense... How did it go? "For extra privacy that message had been
twice encrypted with ROT13"...
On 3 Nov 2002, Alan Cox wrote:
> The problem with this is its nontrivial to set up all the rules. Being
> able to use namespaces to revoke rights is a big help. If we were to add
> a capability for 'getting out of chroot' then we can also combine it
> with chroot to drop users into an unpriviledged universe from which they
> cannot escape because we took away the chroot stuff and we took away
> rawio and so on
No messing with chroot needed - just a way to irrevertibly turn off the
ability (for anybody) to do mounts/umounts in a given namespace and ability
to clone that namespace. Then give them ramfs for root and bind whatever
you need in there. No breaking out of that, since there is nothing below
their root where they could break out to...
In article <[email protected]> you wrote:
> So I'd suggest _not_ attaching that capability to the sendmail binary
> itself, or to any inode number of that binary. A binary is a binary is a
> binary - it's just the data. Instead, I'd attach the information to the
> directory entry, either directly (ie the directory entry really has an
> extra field that lists the capabilities) or indirectly (ie the directory
> entry is really just an "extended symlink" that contains not just the path
> to the binary, but also the capabilities associated with it).
If you modify the object you need to find all attached labels to downgrade
it's capabilities. Therefore you need to find a way from the object to the
capabilities stored in various entries.
Greetings
Bernd
In article <[email protected]> you wrote:
> <shrug> that can be done without doing anything to filesystem.
> Namely, turn current "nosuid" of vfsmount into a mask of capabilities.
> Then use bindings instead of links. *Note* - binary _is_ marked suid,
> mask tells which capabilities _not_ to gain.
the suid bit is important, I agree. this will make most security checks not
fail. Problem: runtime checks depend on euid. PErhaps we should even return
a different effective uid (or 0?) if a program is runnign with increased
capabilities?
Greetings
Bernd
In article <[email protected]> you wrote:
> Namespaces is a way to inherit revocation of rights on a large scale (or
> a small one true). #! is a way to handle program specific revocation of
> rights which _is_ filesystem persistent.
#! would be a nice option to increase capabilities on invocation. But the
final target must be linked to the invocation by an entity/revision binding.
Since we do not have modification versions i could think about checksums:
#!#/bin/setcap
10de6c9a339800777c2a8c43a7def924 /bin/ls
+NET_ADMINe
This even will add another integrity checking layer tp the system.
Greetings
Bernd
On 3 Nov 2002, Alan Cox wrote:
> On Sun, 2002-11-03 at 02:03, Linus Torvalds wrote:
> > So I'd suggest _not_ attaching that capability to the sendmail binary
> > itself, or to any inode number of that binary. A binary is a binary is a
> > binary - it's just the data. Instead, I'd attach the information to the
> > directory entry, either directly (ie the directory entry really has an
> > extra field that lists the capabilities) or indirectly (ie the directory
> > entry is really just an "extended symlink" that contains not just the path
> > to the binary, but also the capabilities associated with it).
>
> So what are the semantics for writing to the file. If I modify a setuid
> (or setpartlysetuid) type file then I wan't the setuidness revoked as
> happens now. That is done for very good reason. Your system appears to
> need a scan of the entire file system to find directory references to
> this object, done atomically.
>
> > The reason I like directory entries as opposed to inodes is that if you
> > work this way, you can actually give different people _different_
> > capabilities for the same program. You don't need to have two different
> > installs, you can have one install and two different links to it.
>
> I'll trade 500K of disk space for a working security model especially as
> the case in question is not that common.
Here's a random idea, it has problems, but seems workable to me:
1) Add a standardized exported data structure to your ELF executable
called "KERNEL_PROCESS_CAPABILITIES_v1" or another name you like, and
have it as a fixed-length bit-array (null terminated) of capabilities,
maybe 128 bits for version one. If extensions are needed later, we can
fairly easily extend the length by aliasing it with another name, say
"KERNEL_PROCESS_CAPABILITIES_v2" and sticking the extra bits at the end
of the structure (or create a second structure...).
2) SUID root the binary like normal
This is what the kernel does:
1) Checks if the binary is SUID root (uid 0), if not go on like normal.
2) If SUID root, and it's an ELF execuable, look for the ELF symbol(s)
above; if not present, set uid to 0 and execute.
3) If caps are present, read them in, don't change UID/GID, set the caps,
and execute.
4) If that process executes another process, drop all capabilities
This could (probably be) extended to a.out format. To deal with scripts
and 'binfmt_misc' stuff, you can create a capability called "CAP_WRAPPER"
which allows capabilities to be transferred to the next process. When you
execute that process, the kernel drops only that one flag, denying the
wrapped executable from transferring capabilities.
Here's some advantages:
- No huge and wierd /etc/fstab[.d], and no mounting of files to gain
capabilites, or other 'strange things'.
- If the kernel doesn't recognize capabilites, it'll just SUID root the
binary like normal
- If the binary doesn't have capabilities listed, it'll just get SUID
root like normal
- Changing the binary still drops SUID root, and thus drops the
capabilites
- User can create wrapper 'binaries' fairly simply
- Since the size of the bitfield for the capabilities is fixed, the user
can modify capabilites inside a binary with that structure.
Problems:
- It's binary, not text, so possibly harder to read without tools.
- Stripped binaries. This could be fixed by a small change:
Instead of using a symbol to look up capabilites, use text in the
executable eg:
struct caps_t {
int magic;
char name[28];
char caps[8];
} kern_proc_caps =
{0x1234AA55, "KERNEL_PROCESS_CAPSTRING_v1", ... };
Comments?
Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu
http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif
Alexander Viro <[email protected]> writes:
> On Sun, 3 Nov 2002, Olaf Dietsche wrote:
>
>> > And as Al points out, new security features don't mean that you can just
>> > stop being careful.
>>
>> Stating the obvious. Capabilities are not an end in itself, nor is suid
>> root. It's just another line of defense to help with these binaries,
>> which are _not_ capability aware.
>
> Bullshit. To _be_ careful you need to understand the implications of
> what you are doing.
Where did I, or anyone else, state the opposite?
> To do so in a more complicated model is harder,
> not easier.
Because it's harder for you to do a proper job, doesn't mean it is for
everybody else.
> More features != better security. Quite often it's exact opposite.
> Human do make errors, otherwise suid-root stuff wouldn't be a problem
> to start with. And when security mechanism increases probability
> of error it becomes a menace.
Capabilities are not about adding features, they are about reducing.
Face it, you just don't get it.
> Odds of getting screwed are 0 if programs contain no bugs. We are dealing
> with real world and there are non-zero odds of exploitable holes being there
> and getting found. What we want is to decrease the odds of compromise,
> right? So how are ACLs/capabilities/etc. settings different from program
> internals? Either can contain bugs. Neither is guaranteed to be done
> correctly. Odds of compromise depend on odds of bugs in both. Yet you
> seem to imply that metadata *will* be set correctly. By the same vendors
> that had shipped vulnerable binary in the first place. Even though the
> complexity of metadata had grown.
Agreed in _every_ _single_ _point_. But because there might be stupid
vendors out there, doesn't mean I have to bow down to their level.
And that is, what this is all about. I want to have this choice and
fortunately, I have it.
> Please, get real. "Completely understood" is much more important than
> "versatile" when it comes to security models. And as for additional lines
So, what's your point? Like with suid root, capability settings need
to be debugged, bug reports filed and people educated.
> of defense... How did it go? "For extra privacy that message had been
> twice encrypted with ROT13"...
Well, _that_ is bullshit.
Regards, Olaf.
On Sun, 3 Nov 2002, Olaf Dietsche wrote:
> > To do so in a more complicated model is harder,
> > not easier.
>
> Because it's harder for you to do a proper job, doesn't mean it is for
> everybody else.
Huh?
> > More features != better security. Quite often it's exact opposite.
> > Human do make errors, otherwise suid-root stuff wouldn't be a problem
> > to start with. And when security mechanism increases probability
> > of error it becomes a menace.
>
> Capabilities are not about adding features, they are about reducing.
> Face it, you just don't get it.
Face it, you either just can't read or are deliberately being obtuse.
New mechanism for raising capabilities doesn't have to be about adding
features, IT IS A NEW FEATURE ITSELF.
Now, fuck off. To .procmailrc you go...
On Sun, Nov 03, 2002 at 04:20:08PM +0100, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > Namespaces is a way to inherit revocation of rights on a large scale (or
> > a small one true). #! is a way to handle program specific revocation of
> > rights which _is_ filesystem persistent.
>
> #! would be a nice option to increase capabilities on invocation. But the
> final target must be linked to the invocation by an entity/revision binding.
> Since we do not have modification versions i could think about checksums:
Unfortenately it will be much harder to find all executables with
increased capabilities on your system.
--
Ragnar Kj?rstad
Big Storage
On Sun, 2002-11-03 at 14:51, Alexander Viro wrote:
> No messing with chroot needed - just a way to irrevertibly turn off the
> ability (for anybody) to do mounts/umounts in a given namespace and ability
> to clone that namespace. Then give them ramfs for root and bind whatever
> you need in there. No breaking out of that, since there is nothing below
> their root where they could break out to...
mkdir foo
chroot foo
cd ../../../..
chroot .
Alan
On 3 Nov 2002, Alan Cox wrote:
> On Sun, 2002-11-03 at 14:51, Alexander Viro wrote:
> > No messing with chroot needed - just a way to irrevertibly turn off the
> > ability (for anybody) to do mounts/umounts in a given namespace and ability
> > to clone that namespace. Then give them ramfs for root and bind whatever
> > you need in there. No breaking out of that, since there is nothing below
> > their root where they could break out to...
>
> mkdir foo
> chroot foo
> cd ../../../..
> chroot .
... will give him nothing, since he is not in chroot jail to start with.
He has a namespace of his own with his own root filesystem. Which has
several empty directories and nothing else - everything else is bound on
these. He is at his absolute root and can't break out of it - there is
nowhere to break out. So his /foo will be a subdirectory of root of his
root filesystem. OK, he chroots there. His cwd is still at absolute root
and he can follow .. until he's blue in the face - he will stay where he
started.
On Sun, 2002-11-03 at 16:30, Ragnar Kj?rstad wrote:
> On Sun, Nov 03, 2002 at 04:20:08PM +0100, Bernd Eckenfels wrote:
> > In article <[email protected]> you wrote:
> > > Namespaces is a way to inherit revocation of rights on a large scale (or
> > > a small one true). #! is a way to handle program specific revocation of
> > > rights which _is_ filesystem persistent.
> >
> > #! would be a nice option to increase capabilities on invocation. But the
> > final target must be linked to the invocation by an entity/revision binding.
> > Since we do not have modification versions i could think about checksums:
>
> Unfortenately it will be much harder to find all executables with
> increased capabilities on your system.
You need a way to mark applications which may be run with increased
capabilities and which ones are permitted yes, and by object not by name
On Sun, Nov 03, 2002 at 05:30:16PM +0100, Ragnar Kj?rstad wrote:
> Unfortenately it will be much harder to find all executables with
> increased capabilities on your system.
Depends if you insert the capabilities/checksum into single files all over
your file system or in a central /etc/capabilities.conf file. The later is a
bit like other security linux distributions and has clearly the advantage of
beeing more obvious.
The scheme could be extended for non capability related integrity checking.
For exampel all root programs need to be listed there with checksums or
someting like that.
Greetings
Bernd
On Sun, Nov 03, 2002 at 11:56:22AM -0500, Alexander Viro wrote:
>
>
> On 3 Nov 2002, Alan Cox wrote:
>
> > On Sun, 2002-11-03 at 14:51, Alexander Viro wrote:
> > > No messing with chroot needed - just a way to irrevertibly turn off the
> > > ability (for anybody) to do mounts/umounts in a given namespace and ability
> > > to clone that namespace. Then give them ramfs for root and bind whatever
> > > you need in there. No breaking out of that, since there is nothing below
> > > their root where they could break out to...
> >
> > mkdir foo
> > chroot foo
> > cd ../../../..
> > chroot .
>
> ... will give him nothing, since he is not in chroot jail to start with.
> He has a namespace of his own with his own root filesystem. Which has
> several empty directories and nothing else - everything else is bound on
> these. He is at his absolute root and can't break out of it - there is
> nowhere to break out. So his /foo will be a subdirectory of root of his
> root filesystem. OK, he chroots there. His cwd is still at absolute root
> and he can follow .. until he's blue in the face - he will stay where he
> started.
Plan 9 !
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
1+ 505 838 9109
On Sun, 3 Nov 2002 [email protected] wrote:
>
> Plan 9 !
Well, yes. But also Linux. The code is all there, and you can create a new
namespace group with just a simple CLONE_NEWNS. Then you just do
pivot_root() in that namespace, unmount the old root, and you're done.
Yeah, yeah, I'm sure I forgot something, glossed over the details, and a
real example is more involved. And I'm also sure it hasn't been used in
practice all that much, but Al's point is that this is much more than
"chroot()", and is actually safe from all the normal chroot problems.
Because the namespace is not a part of the old tree - it's a completely
new tree with no connections to the old one.
We got it pretty much for free (*) with the vfsmount stuff - which in turn
was needed for bind-mounts.
Linus
(*) Although, to be honest, it's hard to say how much of it was "for
free", and how much of it was the normal "Al thinking ahead a year or so
while doing incremental patches". Al is scary that way.
On Sun, Nov 03, 2002 at 10:13:37AM -0800, Linus Torvalds wrote:
>
> On Sun, 3 Nov 2002 [email protected] wrote:
> >
> > Plan 9 !
>
> Well, yes. But also Linux. The code is all there, and you can create a new
> namespace group with just a simple CLONE_NEWNS. Then you just do
> pivot_root() in that namespace, unmount the old root, and you're done.
So capabilities then just seems like a hack. You can write a trusted
user space suid gateway program that consults a database, builds you a
temporary file system with links and permissions to an otherwise hidden
shared tree and puts you safely in that "temporary tree". If I understand
what this does.
As for Al, he may be a great programmer, but it's his polemical
writing style I appreciate most.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
1+ 505 838 9109
On Sun, 3 Nov 2002 [email protected] wrote:
>
> So capabilities then just seems like a hack. You can write a trusted
> user space suid gateway program that consults a database, builds you a
> temporary file system with links and permissions to an otherwise hidden
> shared tree and puts you safely in that "temporary tree". If I understand
> what this does.
That works for stuff where you are willing to live in a very limited
environment.
Most people aren't willing to live in such environments. They want to look
up user files in ~/.xxxxx, falling back to /usr/lib/xxxx/config, etc. And
they want to take advantage of being able to use other programs in the
system etc etc.
In other words, yes, you can create a temporary tree, and pretty much
arbitrarily restrict what any process can actually see of the filesystem.
But it's a _lot_ of work, and requires a lot of care, and by limiting your
filesystem view you limit yourself to only using that view.
And the fact is, most programmers are lazy. They don't want to go to that
effort, since it makes it harder for them. And you can't really blame them
for that - especially since 99% of all projects evolve from something
where security wasn't a big deal ("it's only for my own use anyway").
Look at how few programs bother with chroot(), and that's a lot easier to
use (and portable).
Linus
PS. Yeah, to some degree namespaces are at least in theory easier to use
than chroot, since they allow for a lot more flexibility and you can
cherry-pick and do things like just re-mount /usr/bin with nosuid inside
your namespace, which chroot doesn't allow. With chroot you end up having
to copy the files explicitly and maintain a separate chroot directory
structure.
On Sun, Nov 03, 2002 at 12:16:02AM -0700, Dax Kelson wrote:
>
> Speaking of user 'nobody', modern best practices (and shipped vendor
> configuration) strongly discourages lumping everything under 'nobody'.
>
> Each app should run in its own security context by itself. That is why
> I have all the following users in my /etc/passwd:
>
> apache nscd squid xfs ident rpc pcap nfsnobody radvd gdm named ntp
As a side issue each of these "users", or most of them, has likely also
its own group and one needs also few groups for other purposes. Seems
like the next potential point to bump into a numbers of groups barrier
although probably most of these does not need to be shared. Still if
this will become a part of a widely used security mechanisms there could
be extra demands on memberships.
Michal
On Sun, Nov 03, 2002 at 12:51:40PM +0000, Alan Cox wrote:
> On Sun, 2002-11-03 at 04:20, Linus Torvalds wrote:
> > - do a complete "find" over the whole system to show that there is not a
> > single suid binary anywhere.
>
> Thats a hard problem. Since your scan is non atomic and because you have
> directory notifications a running processes can have the setuid apps can
> move the setuid bits around the file system to hide from you.
I'm fairly certain that Linus was imagining a pre-compromise
vulnerability assessment scan, not a post-compromise "figure out where
the new holes are" scan, honestly. (You don't even need to have
directory notifications, if you've got a process that is tormenting you
like that, find can just be setup to not report certain things, etc
etc.)
--
Ryan Anderson
sometimes Pug Majere
On Sat, Nov 02, 2002 at 11:07:24PM -0700, Dax Kelson wrote:
> /etc/crontab & /etc/cron.(hourly|daily|weekly|monthly)/ & /etc/cron.d/
> /etc/logrotate.conf & /etc/logrotate.d/
> /etc/profile & /etc/profile.d/
> /etc/httpd/conf/httpd.conf & /etc/httpd/conf.d/
> /etc/xinetd.conf & /etc/xinetd.d/
> /etc/lvmtab & /etc/lvmtab.d/
> /etc/makedev.d/
> /etc/pam.d/
Or
/usr/lib/menu/ && update-menus
/etc/modutils/ && update-modules
And there are tons of more, like generating mta-config from m4.
--
Anders Gustafsson - [email protected] - http://0x63.nu/
On Sun, 3 Nov 2002, Linus Torvalds wrote:
> (*) Although, to be honest, it's hard to say how much of it was "for
> free", and how much of it was the normal "Al thinking ahead a year or so
> while doing incremental patches". Al is scary that way.
I seem to remember Al talking about the namespace stuff around
2.4.<early>. Good to hear all the incremental pieces have made
it in now ;)
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Sat, Nov 02, 2002 at 06:03:12PM -0800, Linus Torvalds wrote:
> The reason I like directory entries as opposed to inodes is that if you
> work this way, you can actually give different people _different_
> capabilities for the same program. You don't need to have two different
> installs, you can have one install and two different links to it.
For several years, I have had only one suid root binary on my system.
All other 'setuid' applications are simply symlinks to this binary.
$ ls -l /bin/ping*
lrwxrwxrwx 1 root root 14 Nov 18 2001 /bin/ping -> /usr/bin/super
-rwxr-xr-x 1 root root 15244 Nov 18 2001 /bin/ping.suid
There is a a nice configuration file that is used to decide whether to
use suid or setgid, which parts of the environment to drop/keep. And all
of this based on the user, the time and any other conditions I would
like to enforce.
Now super does not (yet) support capabilities. But it shouldn't be too
hard to modify it so that it forks, drops capabilities, (possibly change
the euid to the original user?) and exec the actual binary.
Jan
Dax Kelson <[email protected]> wrote:
> Each app should run in its own security context by itself. That is why
> I have all the following users in my /etc/passwd:
>
> apache nscd squid xfs ident rpc pcap nfsnobody radvd gdm named ntp
Well, wouldn't it be then logical to associate uids to capabilities, e.g. I
could have ping binary setuid to user ping which would have just the
necessary capabilities to operate?
--
Antti Salmela
Antti Salmela <[email protected]> writes:
> Dax Kelson <[email protected]> wrote:
>
>> Each app should run in its own security context by itself. That is why
>> I have all the following users in my /etc/passwd:
>>
>> apache nscd squid xfs ident rpc pcap nfsnobody radvd gdm named ntp
>
> Well, wouldn't it be then logical to associate uids to capabilities, e.g. I
> could have ping binary setuid to user ping which would have just the
> necessary capabilities to operate?
Welcome to accessfs :-)
<http://groups.google.com/groups?selm=87k7km9fti.fsf%40goat.bogus.local>
<http://groups.google.com/groups?selm=87elau9ft2.fsf%40goat.bogus.local>
<http://groups.google.com/groups?selm=878z129fnz.fsf%40goat.bogus.local>
It's not exactly what you asked for, but I think it's the closest you
can get at the moment.
Regards, Olaf.
Sun, 03 Nov 2002 05:50:24 -0500: Hacksaw (Hacksaw
<[email protected]>):
> I still find "mount --bind --capability=xx,yy /usr/bin/foo
> /usr/bin/foo" to be a strange syntax. It implies that one is mounting
> /usr/bin/foo over /usr/bin/foo, and adding the xx,yy capabilities.
This could be an argument _for_ doing it this way. As a sysadmin myself,
this makes a lot of sense to me, and being able to catch it by looking
in a 'mount' command is certainly a sweet proposal-- That way you can
constantly monitor anything that needs extra capabilities very simply.
And if mount supported an argument to ONLY show capability remounts,
there's a quick 'showcap' for you.
--
< There is a light that shines on the frontier >
< And maybe someday, We're gonna be there. >
< Rando Christensen / [email protected] >
On Sun, Nov 03, 2002 at 01:37:19AM -0500, Alexander Viro wrote:
> > In other words, it would actually make perfect sense to have
> >
> > -r-sr-sr-x 1 nobody mail 451280 Apr 8 2002 /usr/bin/sendmail
> >
> > mount --bind --capability=chown,bindlow /usr/bin/sendmail /usr/bin/sendmail
>
> *blam*
>
> Congratulations with potential crapload of security holes - now anyone
> who'd compromised a process running as nobody can chmod the damn thing
> and modify it.
>
> And that is the reason why suid-nonroot is bad. It creates a class of
> binaries that can easily give you a root compromise if one of them has
> an exploit - even if that one is never run by root.
This is solved by some implementations of POSIX capabilities by
zapping any capabilities if the executible is modified --- just as
some Unix systems zap the setuid bit if the executable is modified.
It addresses specifically the problem that you've raised.
- Ted
On Sun, Nov 03, 2002 at 09:49:10PM -0500, Jan Harkes wrote:
> For several years, I have had only one suid root binary on my system.
> All other 'setuid' applications are simply symlinks to this binary.
>
> $ ls -l /bin/ping*
> lrwxrwxrwx 1 root root 14 Nov 18 2001 /bin/ping -> /usr/bin/super
> -rwxr-xr-x 1 root root 15244 Nov 18 2001 /bin/ping.suid
>
> There is a a nice configuration file that is used to decide whether to
> use suid or setgid, which parts of the environment to drop/keep. And all
> of this based on the user, the time and any other conditions I would
> like to enforce.
>
> Now super does not (yet) support capabilities. But it shouldn't be too
> hard to modify it so that it forks, drops capabilities, (possibly change
> the euid to the original user?) and exec the actual binary.
This sounds like the right way to go. I do hope the configuration
file includes an SHA checksum of the secutable. And to avoid race
conditions, there really ought to be a new system call, fexecve(2)
which takes an open file descriptor instead of a pathname.
(Unfortunately, we're in feature freeze now, so that will have to wait
until 2.7.)
Failing that, though, /usr/bin/super should really check the
permissions starting from the root of the entire pathaname, and fail
the exec if any of the containing directories are writable by a
non-root user. (And of course, the executable should not be writable
by a non-root users for the same reason.)
With these checks, though, adding support for capabilities in
/usr/bin/super sounds like the right approach. It doesn't require any
kernel changes (well, fexecve(2) would be nice, but it's not strictly
required). There is of course a slight performance penalty associated
with the use of the helper program, but the start time of most setuid
root programs probably isn't a performance critical concern.
- Ted
On Mon, 2002-11-04 at 14:50, Theodore Ts'o wrote:
> This sounds like the right way to go. I do hope the configuration
> file includes an SHA checksum of the secutable. And to avoid race
> conditions, there really ought to be a new system call, fexecve(2)
> which takes an open file descriptor instead of a pathname.
> (Unfortunately, we're in feature freeze now, so that will have to wait
> until 2.7.)
execve /proc/self/fd/n ???
On Saturday 02 November 2002 12:47 pm, Linus Torvalds wrote:
> Clearly inode numbers are a bad way to handle it, but I don't think inode
> attributes are that great either. I would personally prefer directory
> entry attributes, so that the same file can show up with different
> behaviour in different places.
So how would hard links be handled? Ignore the capability specified for
the file?
> I think it was a mistake to have permissions be part of the inode in the
> first place, but that's UNIX for you. A direntry-based approach is _so_
> much more flexible, and doesn't really have any downsides.
That was a conscious decision to ensure that the ownership, and mode
bits remained associated with a file no matter how the file is accessed (full
path, relative path, hard link, or inode number). It also meant that there was
only one place that might need to be updated if the permissions were
changed. If they were in directories then all directories containing a
link to the file would have to be updated (assuming you could find them
efficiently).
Since all accesses HAD to go through the inode, it forced the security
information to be united with the file, and could not be misplaced.
> (Having attributes in the direntry also makes it possible to much more
> efficiently scan directories for types of files without having to look up
> the inode information).
True, but a hard link would bypass whatever capabilities were assigned
to the file. Also, what happens on things like mv or cp. Since mv
only puts a name in the target directory with the inode number it
would appear that any capabilities assigned to the file would be lost.
Although cp should loose the capabilities, I would expect mv to preserve them.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
I see no one has responded to this yet, so I'll ask again.
Does anyone have any comments about my idea outlined below?
Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu
http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif
On Sun, 3 Nov 2002, Patrick Finnegan wrote:
> On 3 Nov 2002, Alan Cox wrote:
>
> > On Sun, 2002-11-03 at 02:03, Linus Torvalds wrote:
> > > So I'd suggest _not_ attaching that capability to the sendmail binary
> > > itself, or to any inode number of that binary. A binary is a binary is a
> > > binary - it's just the data. Instead, I'd attach the information to the
> > > directory entry, either directly (ie the directory entry really has an
> > > extra field that lists the capabilities) or indirectly (ie the directory
> > > entry is really just an "extended symlink" that contains not just the path
> > > to the binary, but also the capabilities associated with it).
> >
> > So what are the semantics for writing to the file. If I modify a setuid
> > (or setpartlysetuid) type file then I wan't the setuidness revoked as
> > happens now. That is done for very good reason. Your system appears to
> > need a scan of the entire file system to find directory references to
> > this object, done atomically.
> >
> > > The reason I like directory entries as opposed to inodes is that if you
> > > work this way, you can actually give different people _different_
> > > capabilities for the same program. You don't need to have two different
> > > installs, you can have one install and two different links to it.
> >
> > I'll trade 500K of disk space for a working security model especially as
> > the case in question is not that common.
>
> Here's a random idea, it has problems, but seems workable to me:
>
> 1) Add a standardized exported data structure to your ELF executable
> called "KERNEL_PROCESS_CAPABILITIES_v1" or another name you like, and
> have it as a fixed-length bit-array (null terminated) of capabilities,
> maybe 128 bits for version one. If extensions are needed later, we can
> fairly easily extend the length by aliasing it with another name, say
> "KERNEL_PROCESS_CAPABILITIES_v2" and sticking the extra bits at the end
> of the structure (or create a second structure...).
>
> 2) SUID root the binary like normal
>
> This is what the kernel does:
>
> 1) Checks if the binary is SUID root (uid 0), if not go on like normal.
>
> 2) If SUID root, and it's an ELF execuable, look for the ELF symbol(s)
> above; if not present, set uid to 0 and execute.
>
> 3) If caps are present, read them in, don't change UID/GID, set the caps,
> and execute.
>
> 4) If that process executes another process, drop all capabilities
>
> This could (probably be) extended to a.out format. To deal with scripts
> and 'binfmt_misc' stuff, you can create a capability called "CAP_WRAPPER"
> which allows capabilities to be transferred to the next process. When you
> execute that process, the kernel drops only that one flag, denying the
> wrapped executable from transferring capabilities.
>
> Here's some advantages:
> - No huge and wierd /etc/fstab[.d], and no mounting of files to gain
> capabilites, or other 'strange things'.
> - If the kernel doesn't recognize capabilites, it'll just SUID root the
> binary like normal
> - If the binary doesn't have capabilities listed, it'll just get SUID
> root like normal
> - Changing the binary still drops SUID root, and thus drops the
> capabilites
> - User can create wrapper 'binaries' fairly simply
> - Since the size of the bitfield for the capabilities is fixed, the user
> can modify capabilites inside a binary with that structure.
>
> Problems:
> - It's binary, not text, so possibly harder to read without tools.
> - Stripped binaries. This could be fixed by a small change:
>
> Instead of using a symbol to look up capabilites, use text in the
> executable eg:
>
> struct caps_t {
> int magic;
> char name[28];
> char caps[8];
> } kern_proc_caps =
> {0x1234AA55, "KERNEL_PROCESS_CAPSTRING_v1", ... };
>
> Comments?
>
> Pat
> --
> Purdue Universtiy ITAP/RCS
> Information Technology at Purdue
> Research Computing and Storage
> http://www-rcd.cc.purdue.edu
>
> http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif
>
>
> -
> 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/
>
On Saturday 02 November 2002 10:54 pm, Linus Torvalds wrote:
> On Sat, 2 Nov 2002, Alexander Viro wrote:
> > No, that's OK -
> >
> > mount --bind /usr/bin/foo.real /usr/bin/foo.real
> > mount -o remount,nosuid /usr/bin/foo.real
>
> Ehh. With the nosuid mount that will remove the effectiveness of the suid
> bit (not just the user change - it will also mask off the elevation of the
> capabilities), so the bind-mount with the capability mask will now mask
> off nothing to start with.
>
> Wouldn't it be much nicer to have:
>
> /usr/bin/foo - no suid bits, no capabilities by default
>
> mount --bind --capability=xx,yy /usr/bin/foo /usr/bin/foo
>
> where the mount actually adds capabilities? Looks more understandable to
> me.
Only until the file the path name is connected to is replaced. Then the
trojan suddenly gains the capabilities of the real "foo".
Been there done that. That was one of the first security vulnerabilities
in the VMS implementation of ACLs.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Patrick Finnegan <[email protected]> writes:
> I see no one has responded to this yet, so I'll ask again.
>
> Does anyone have any comments about my idea outlined below?
[... capabilities in elf executables ...]
Take a look at <http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html>.
Maybe this is what you had in mind?
Regards, Olaf.
On Mon, 4 Nov 2002, Olaf Dietsche wrote:
> Patrick Finnegan <[email protected]> writes:
>
> > I see no one has responded to this yet, so I'll ask again.
> >
> > Does anyone have any comments about my idea outlined below?
> [... capabilities in elf executables ...]
>
> Take a look at <http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html>.
> Maybe this is what you had in mind?
Similar, but not exactly the same:
1) Capabilities should be enabled explicitly not dropped explicitly -
it's a 'more secure' way to do it.
2) Capabilities shouldn't be preserved across an execve except for once,
as needed by wrapper scripts/binaries. This way even if someone figures
out how to exploit the code to do an exec, they're left with no caps at
all. If desired, a new binfmt "cap_wrap" could be created that can be
used as a capabilities wrapper for executables, which the kernel looks
at to determine 1) what caps to use and 2) what binary to run. The
wrapper will need to be suid root in order to gain caps still.
3) Defining a new ELF header seems to me like it could (potentially) break
backward/forward compatibility. My method preserves compatibility,
with the only difference being if the app really gets capabilities or
if it gets SUID root instead. If this really isn't a problem, you can
take the works 'ELF Symbol' and change them to 'ELF Header' and make
the idea still work the same in other aspects.
4) If the app has capabilities associated with it, no userspace code is
run as uid 0, the kernel can avoid even changing uid during the execve
syscall. It's just treated as a caps flag unless the kernel determines
that the file has no capabilities, and then can run it as suid root.
Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu
http://dilbert.com/comics/dilbert/archive/images/dilbert2040637020924.gif
Patrick Finnegan <[email protected]> writes:
> On Mon, 4 Nov 2002, Olaf Dietsche wrote:
>
>> Take a look at <http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html>.
>> Maybe this is what you had in mind?
>
> Similar, but not exactly the same:
>
> 1) Capabilities should be enabled explicitly not dropped explicitly -
> it's a 'more secure' way to do it.
>
> 2) Capabilities shouldn't be preserved across an execve except for once,
For this you need to clear the permitted and inheritable set.
> as needed by wrapper scripts/binaries. This way even if someone figures
> out how to exploit the code to do an exec, they're left with no caps at
> all. If desired, a new binfmt "cap_wrap" could be created that can be
> used as a capabilities wrapper for executables, which the kernel looks
> at to determine 1) what caps to use and 2) what binary to run. The
> wrapper will need to be suid root in order to gain caps still.
Here you will find capabilities with a new binfmt type:
<http://groups.google.com/groups?selm=linux.kernel.20020317121118.A18548%40glacier.arctrix.com>
Elfcap and capwrap both allow to have capabilities.
Regards, Olaf.
On Fri, 1 Nov 2002, Jan Harkes wrote:
[snip]
> In the end I believe capabilities (like setuid) should be a local
> decision. Yes, I'm looking at this from the viewpoint of a distributed
> network filesystem that crosses administrative boundaries, and as such I
> don't always trust whatever is stored in a mounted volume.
>
> Why not modify a program like sudo or super that can give capabilities
> to processes based on local rules and configuration... Ok there already
> is a programs that does something like this which is called 'whichcap'.
>
> Another solution is to have a trusted daemon that is the only process
> in the system with the capability to grant capabilities to other
> proceses. Other processes can send a request to this daemon, which can
> consult local rules, double check md5 checksum or whatever paranoia is
> needed before it actually does a setcap.
You might want to look at the VMS model. The sysadmin creates a startup
script that tells the kernel which files are to be granted "amplified
privileges" when activated. There's a dab of kernel code to maintain and
implement this list, but there's zero filesystem code involved because
these are not metadata. The kernel holds each "installed" file open as
long as it's installed, so there's NO way to replace a trusted file
without admin. priv.s -- you have to uninstall the file before you can
monkey with it, and there's a priv. which controls the ability to do
that.
--
Mark H. Wood, Lead System Programmer [email protected]
MS Windows *is* user-friendly, but only for certain values of "user".
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alan Cox wrote:
> execve /proc/self/fd/n ???
Inspired by this and because Alan of course cannot be wrong about
something as simple as this I went on and implemented it. Just to jind
that it's not working properly. Try this:
$ echo -e "#! /bin/sh\necho u1" > u1
$ chmod +x u1
$ echo -e "#! /bin/sh\necho u2" > u2
$ chmod +x u2
$ cat u.c
int
main()
{
system ("cp -f u1 uu");
int fd = open ("./uu", 0);
char buf[100];
sprintf (buf, "/proc/self/fd/%d", fd);
char buf2[100];
int n = readlink (buf, buf2, sizeof (buf2));
buf2[n] = '\0';
system ("cp -f u2 uu");
execl (buf, buf2, "hallo", 0);
return 0;
}
$ gcc -c o u u.c
$ ./u
You should see 'u2' as the result. But this is exactly what the fexecve
call is supposed to prevent. The file, once opened, should be reused.
The expected result is 'u1'.
The problem is, as you can see from the readlink call in strace's
output, that /proc/self/fd/XXX is used as a symlink in the execve call.
The symlink of course refers to 'u2'.
And thinking back, I did try to write fexecve like this back when...
Anyway, any solution to this is welcome since the missing fexecve is
regularly asked for.
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9xtor2ijCOnn/RHQRAgHQAJ9YsYVnX9rKVYf9Rzy4fgUx5195pgCghnXC
b5ZIJ1+vivZ2pWTmLxdrXtc=
=vJwO
-----END PGP SIGNATURE-----
On Mon, 4 Nov 2002, Ulrich Drepper wrote:
> int
> main()
> {
> system ("cp -f u1 uu");
> int fd = open ("./uu", 0);
> char buf[100];
> sprintf (buf, "/proc/self/fd/%d", fd);
> char buf2[100];
> int n = readlink (buf, buf2, sizeof (buf2));
> buf2[n] = '\0';
> system ("cp -f u2 uu");
> execl (buf, buf2, "hallo", 0);
> return 0;
> }
> $ gcc -c o u u.c
> $ ./u
>
>
> You should see 'u2' as the result. But this is exactly what the fexecve
> call is supposed to prevent. The file, once opened, should be reused.
> The expected result is 'u1'.
No, you're wrong.
Your "cp -f" will _overwrite_ the already existing "uu" file. So the "cp"
is actually overwriting the old binary, and it prints out "u2" as a
result: which is exactly the expected behaviour of "fexecve()". If you
change the file itself, there's no way to execve() the old contents,
because the old contents simply do not exist. That's true of fexecve()
too.
To show what you want to show, you need to use "cp -fb" or something else
that actually _switches_ the file around from under you. Or make the
system() call do a "rm uu; cp uX uu". And if you do that, then you will
see "u1". Try it and see.
In other words, "execve(/proc/self/fd/xxx)" does work and is exactly the
same as fexecve().
Linus
Hello,
I'be been reading this discussion with interest, but it seems like people
are missing the obvious. There's already an infrastructure in 2.5 that is
perfect for features like this: the LSM. Consider the advantages:
1) It's filesystem independent, and doesn't bloat the filesystem, VFS, and
exec code. Just hook the exec call in an LSM module and twiddle the
permissions appropriately according to policy.
2) More importantly, this kind of feature isn't really that useful on its
own, but makes the most sense in the context of overall system security,
which is exactly what LSM is designed to enable.
I haven't studies the LSM in any detail, but I'm sure the appropriate hooks
to implement this kind of policy are either available already, or easily
added.
_________________________________________________________________
Broadband??Dial-up? Get reliable MSN Internet Access.
http://resourcecenter.msn.com/access/plans/default.asp
On Friday 01 November 2002 19:32, Dax Kelson wrote:
> On Fri, 2002-11-01 at 01:49, Rusty Russell wrote:
> > I'm down to 8 undecided features: 6 removed and one I missed earlier.
>
> How about Olaf Dietsche's filesystem capabilities support? It has been
> posted a couple times to LK, yesterday even.
>
>
> We've had capabilities for ages (2.2?) but no filesystem support.
>
> OpenBSD is recently bragging about no longer having any SUID root
> binaries on the system.
>
> With FS capabilities we (Linux) can have the same situation. Security
> is a hot topic, and anything the kernel can do make security
> better/easier seems worthy of consideration.
We have little experience with full blown capability enabled systems. Rushing
things doesn't seem like a good idea. IMO we should wait until vendors have
integrated FS caps before adding this to the standard kernel.
--Andreas.
On Sat, Nov 02, 2002 at 06:05:09PM -0800, Linus Torvalds wrote:
>
> On Sat, 2 Nov 2002, David D. Hagood wrote:
> > Linus Torvalds wrote:
> > >
> > > And pathnames are a _hell_ of a lot better and straightforward interface
> > > than inode numbers are. It's confusing when you change the permission on
> > > one path to notice that another path magically changed too.
> >
> > Would this not allow a user to add permissions to a file, by creating a
> > new directory entry and linking it to an existing inode?
> >
> > Would that not be a greater security hole?
>
> No. The file itself has _no_ capabilities at all. If you just link to it,
> you can give it whatever capabilities _you_ have as a user (well, normal
> users don't really have any capabilities to give, but you get the idea).
Capabilties done right, means that normal users DO have capabilities.
Normal users have the capability to call normal syscalls like "read",
"write" and "execve".
And once you have these included in the capabilities (which normal users
and programs normally have by default), you can take them away if you
want. For example, a non-scripting webserver may not require any use of
the "execve" system call.
Oh, it's easy to get a "vector" of over 100 capabilities this way. This
might be inefficient. Thus, it would be required that we get two levels:
first level as you're thinking of it: split capabilities for what
"root" now has, and the other also splitting the "normal user"'s
capabilities (and splitting the root-kinds even further).
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 currently in such an *
* excursion: The stable situation does not include humans. ***************
In article <[email protected]> you wrote:
> Capabilties done right, means that normal users DO have capabilities.
> Normal users have the capability to call normal syscalls like "read",
> "write" and "execve".
This is IMHO very desireable, but not part of POSIX capabilties and also
even more intrusive on the applications.
Even on Windows NT you do not have such User capabilties. With a good
namespace and ACL concept, you can get around it, most of the time.
(although a object based security is not always as good as a subject bound).
Greetings
Bernd
On Sunday 03 November 2002 04:36, Dax Kelson wrote:
> The principle of least privilege says that instead of a system full of
> binaries running as root, we should have a system of binaries running as
> non-root with only the capabilities they need.
>
> The typical break-in involves gaining non-root access first, then doing a
> privilege escalation attack to gain root. A system using capabilities
> makes the escalation attack must more difficult.
>
> How are we currently doing? The following (pathetically short list of)
> binaries use capabilities:
>
> vsftpd
> ntptimeset
> ntpdate
> ntpd
> named
>
> What are the potential users of capabilities?
>
> 47 SUID root binaries (EVERYTHING install of Red Hat Linux 8.0)
>
> Filesystem capabilities support could take care of these SUID root
> binaries. Historically, SUID root binaries have been heavily used in
> privilege escalation attacks.
>
> How about daemons that are launched as root? These could be potential
> users of capabilities + drop root right now.
>
> There is a snag though. When non-root binaries (eg, daemons running as
> non-root but with capabilities) execve(), all capabilities are cleared, so
> if some of these daemons need to exec other binaries with certain
> capabilities, it currently won't work.
>
> "ps aux | grep root" to take a look. We see stuff like:
>
> syslogd
> cardmgr
> apmd
> smartd
> xinetd
> dhclient
> gpm
> crond
> cupsd
> anacron
> rhnsd
> login
> mingetty
> X
>
> This is not an exhaustive list. The system I checked was not running many
> daemons.
>
> In summary, there is lots that could be done today to secure daemons. The
> clearing of capabilities on exec by non-root binaries needs be addressed
> (I posted a patch in May 2002). File system capabilities support can
> fix the large amount of SUID root binaries that exist. OpenBSD 3.2
> (just released) has started to implement a similar technique to get rid
> of SUID root binaries.
>
> Once filesystem capabilities is added to the kernel, RPM and DPKG should
> be fixed so that, otherwise SUID root binaries, can be installed with
> capabilities support automatically.
I agree that package managers should eventually be made aware of capabilities,
like they are now aware of file modes/ownership. There are several other
configuration issues to figure out that may depend on the overall purpose of
a system, like which user(s) are granted which capabilities when logging in,
checking the capabilities of installed binaries, etc.
> This should be the vendors / package maintainers job. The average sysadmin
> should get the benefits without having to think about it.
Yes.
--Andreas.
Andreas Gruenbacher <[email protected]> writes:
> On Friday 01 November 2002 19:32, Dax Kelson wrote:
>>
>> With FS capabilities we (Linux) can have the same situation. Security
>> is a hot topic, and anything the kernel can do make security
>> better/easier seems worthy of consideration.
>
> We have little experience with full blown capability enabled systems. Rushing
And it will stay that way, if we don't start now.
> things doesn't seem like a good idea. IMO we should wait until vendors have
> integrated FS caps before adding this to the standard kernel.
Fact is, we have a capability enabled system for quite some time. It's
just not making any progress regarding fs caps. But I must admit, that
it may not be the time to include them into the mainstream kernel. On
the other hand, if there were an implementation from someone Linus
trusts, I'm sure he won't hesitate to include it right away.
BTW, it's really amazing how many people argue _against_ and how few
are working _for_ fs capabilities. And it's not that anybody has shown
real arguments against. Mostly uneasy fealings, eventual scenarios and
bashing of stupid vendors and foolish sysadmins. This might score some
points here and there, but it is not really helpful.
Anyway, have a nice time waiting. ;-)
Regards, Olaf.
--
Filesystem capabilities implemented, installed and running right now.
On Tuesday 05 November 2002 15:48, Olaf Dietsche wrote:
> Andreas Gruenbacher <[email protected]> writes:
> > On Friday 01 November 2002 19:32, Dax Kelson wrote:
> >> With FS capabilities we (Linux) can have the same situation. Security
> >> is a hot topic, and anything the kernel can do make security
> >> better/easier seems worthy of consideration.
> >
> > We have little experience with full blown capability enabled systems.
> > Rushing
>
> And it will stay that way, if we don't start now.
>
> > things doesn't seem like a good idea. IMO we should wait until vendors
> > have integrated FS caps before adding this to the standard kernel.
>
> Fact is, we have a capability enabled system for quite some time. It's
> just not making any progress regarding fs caps.
> But I must admit, that it may not be the time to include them into
> the mainstream kernel.
This was my point. After this discussion I am sure the patch won't be merged
for 2.6 anyway.
[...]
> BTW, it's really amazing how many people argue _against_ and how few
> are working _for_ fs capabilities. And it's not that anybody has shown
> real arguments against. Mostly uneasy fealings, eventual scenarios and
> bashing of stupid vendors and foolish sysadmins. This might score some
> points here and there, but it is not really helpful.
Several pros and cons were brought up. In the end all that counts is whether
the pros are big enough to warrant the cons.
--Andreas.
On Sat, 2 Nov 2002, Linus Torvalds wrote:
> There are two fairly trivial ways to do it:
>
> - put the actual data in the directory entry itself. This is efficient,
> but not very easily extensible, since most directory structures have
> serious size limitations.
I think the arguments against having different capabilities for the same
executable by different names have been made. It does seem that this would
mean a symbolic link to the enabled directory entry would work and have
capabilities, while a hard link to the inode would not?
Being hard to understand is one source of security errors of the "I didn't
mean to do that" type.
> - Make a new file type, and put just that information in the directory
> (so that it shows up in d_type on a readdir()). Put the real data in
> the file, ie make it largely look like an "extended symlink".
I thought about symlink-like thngs when I was trying to envision an ACL by
group, allowing control of a group other than the non-owner group to have
more (or fewer) rights.
> The latter approach is probably a bit too reminiscent of a Windows
> "shortcut" aka LNK file to some people, but hey, maybe it's a good idea.
The problem with any form of link by name is that there's no easy way to
tell from the inode how many pointers there are, and from the link to tell
when the link target has changed. I could envision security attacks based
on changing the base file and having capabilities apply via the link.
None of this is beyond implementation, but the idea of having something on
a file inode certainly removes all attacks taking advantage of the link
relationship. The best way to make something secure is to eliminate the
need for it.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Sat, 2 Nov 2002, Albert D. Cahalan wrote:
>
> I have to wonder, just how many setuid executables do people have?
> Implementing filesystem capability bits in ramfs or tmpfs might do
> the job. At boot, initramfs stuff puts a few trusted executables
> in /trusted and sets the capability bits. Then "mount --bind" to
> put /trusted/su over an empty /bin/su file, or use symlinks.
It's more useful that you might at first think, in terms of applications.
If I have an app I want to make available to a limited group, currently I
can portably make the file setuid to app-owner, then group but not world
executable, and the people in the group can have access. The app might be
a database, usenet news, mail system spam filter, whatever. ACLs work, but
are not widely portable at the moment (if ever).
> One might as well make "nosuid" the default then, and mount the
> root filesystem that way. It's not as if a system needs to have
> gigabytes of setuid executables.
Well, my point here is not that you can't do this, but that normal users
may have legitimate reasons for doing this, and that it's desirable to
avoid having to remount the filesystem to reload some setuid file list.
I would think a mount option which blocks setuid on root owned files and
files which are world writable would be useful. That would allow the
mounting of applications, which people in practice do, without
compromising the whole system.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On 2 Nov 2002, Dax Kelson wrote:
> Most sysadmin can't 'deal with X', where X is:
>
> - Configure kerberos
> - Use setfactl
> - ext2/3 attributes
Most don't need to. The lst time I did Kerberos I believe it was on a
Sun-3. To special use and security issues you might add custom PAM. The
other stuff on your list a good admin should be able to do, although more
sites are using a "vendor kernel only" policy.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Tuesday 05 November 2002 05:47 pm, Bill Davidsen wrote:
> On Sat, 2 Nov 2002, Linus Torvalds wrote:
> > There are two fairly trivial ways to do it:
> >
> > - put the actual data in the directory entry itself. This is efficient,
> > but not very easily extensible, since most directory structures have
> > serious size limitations.
>
> I think the arguments against having different capabilities for the same
> executable by different names have been made. It does seem that this would
> mean a symbolic link to the enabled directory entry would work and have
> capabilities, while a hard link to the inode would not?
>
> Being hard to understand is one source of security errors of the "I didn't
> mean to do that" type.
Not to mention what happens if a file gets lost - fsck puts it in the
lost+found directory, but without the protection specified by the owner.
> > - Make a new file type, and put just that information in the directory
> > (so that it shows up in d_type on a readdir()). Put the real data in
> > the file, ie make it largely look like an "extended symlink".
>
> I thought about symlink-like thngs when I was trying to envision an ACL by
> group, allowing control of a group other than the non-owner group to have
> more (or fewer) rights.
>
> > The latter approach is probably a bit too reminiscent of a Windows
> > "shortcut" aka LNK file to some people, but hey, maybe it's a good idea.
>
> The problem with any form of link by name is that there's no easy way to
> tell from the inode how many pointers there are, and from the link to tell
> when the link target has changed. I could envision security attacks based
> on changing the base file and having capabilities apply via the link.
>
> None of this is beyond implementation, but the idea of having something on
> a file inode certainly removes all attacks taking advantage of the link
> relationship. The best way to make something secure is to eliminate the
> need for it.
absolutely
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Hi!
> > And pathnames are a _hell_ of a lot better and straightforward interface
> > than inode numbers are. It's confusing when you change the permission on
> > one path to notice that another path magically changed too.
>
> It's equally confusing to find out that link(2) doesn't preserve
> file properties.
>
> Frankly, I'm less than sure that ability to raise capabilities is
> a good thing - being able to drop them is certainly nice, but I doubt
> that partial suid-root will be better than full suid-root and it
> certainly makes security model even more complex. And incomplete
I dont think its good idea to add capabilities
this way: make fs capabilities drop only, and
if you want to raise, make it setuid root.
Kernel will see its suid, will raise capabilities, and
then drop them according to the fs fields.
Thats okay, and old apps will see its suid root
and treat it with care.
The only bad thing about this is how to make
something suid games, addcap hw access.
PavelEnd_of_mail_magic_5574
On Sun 03-11-02 16:20:08, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > Namespaces is a way to inherit revocation of rights on a large scale (or
> > a small one true). #! is a way to handle program specific revocation of
> > rights which _is_ filesystem persistent.
>
> #! would be a nice option to increase capabilities on invocation. But the
> final target must be linked to the invocation by an entity/revision binding.
> Since we do not have modification versions i could think about checksums:
>
> #!#/bin/setcap
> 10de6c9a339800777c2a8c43a7def924 /bin/ls
> +NET_ADMINe
I do not think having md5 sum of /bin/ls helps so much -- what if I
moify ld.so, instead?
Pavel
--
When do you have heart between your knees?
On Sat, Nov 09, 2002 at 09:11:21PM +0100, Pavel Machek wrote:
> I do not think having md5 sum of /bin/ls helps so much -- what if I
> moify ld.so, instead?
the checksum is intended to mimic the exisiting priveledge revocatin on
altering. You could of course all all depenendn modules as checksums too,
but this would be more our current suid system supports.
Greetings
Bernd
