Unprivileged: Disable raising of privileges
in [Kernel]
|
Prev: BFS v0.313 CPU scheduler for 2.6.32
Next: ACPI warning from alloc_pages_nodemask on boot (2.6.33 regression)
From: Eric W. Biederman on 31 Dec 2009 13:40 "Andrew G. Morgan" <morgan(a)kernel.org> writes: > Why not implement this as another securebit? So far as I can see the > whole thing can be implemented in the capability LSM. > > What is less clear to me is whether per-process 'disabling of setuid > bits on files' should force mandatory disabling of file capabilities. > It seems as if disabling the transition of one luser to another luser > through a setuid executable is something distinct from privilege > escalation. > > Since there is already independent support for disabling file > capabilities (the privilege escalation part), I see these two > mechanisms as separable. The goal is to disable privilege escalation. The anatomy of the sendmail capabilities bug as I understand it was: - unprivileged process took action to prevent gaining a capability. - exec'd suid sendmail. - sendmail took action as root because it could not become someone else. I would like to trivially stop that entire class of exploit by making execing a suid ( or equivalent ) executable impossible. Once that hole is closed we can enable things like chroot without privilege. If there is a way to express this with capabilities today I would be more than happy to. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 31 Dec 2009 13:50 "Andrew G. Morgan" <morgan(a)kernel.org> writes: > Since there is already independent support for disabling file > capabilities (the privilege escalation part), I see these two > mechanisms as separable. I guess there is something that resembles support for disabling privilege escalation. The problem is that it requires privilege to use it. I have no problem with expressing this in a fine grained manner internally to the kernel but the user space interface needs to be atomic so that we can enable this all without privilege. Further I may be off but I think the implementation would be more challenging than what I have already posted. That doesn't mean it won't be more useful long term. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Serge E. Hallyn on 31 Dec 2009 16:50 Quoting Eric W. Biederman (ebiederm(a)xmission.com): > "Andrew G. Morgan" <morgan(a)kernel.org> writes: > > > Since there is already independent support for disabling file > > capabilities (the privilege escalation part), I see these two > > mechanisms as separable. > > I guess there is something that resembles support for disabling > privilege escalation. The problem is that it requires privilege to > use it. > > I have no problem with expressing this in a fine grained manner internally > to the kernel but the user space interface needs to be atomic so that > we can enable this all without privilege. > > Further I may be off but I think the implementation would be more > challenging than what I have already posted. That doesn't mean it > won't be more useful long term. > > Eric Right, what we can currently do with capabilities is: 1. drop capabilities from the bounding set. This is privileged because it is fine-grained, and can trick capability-unaware privileged programs. 2. drop CAP_SETUID from pP, pI, and the bounding set, to prevent any future setuids. Privileged for the same reason as 1. 3. set SECURE_NOROOT and SECURE_NOSUIDFIXUP, so that uid 0 won't automatically get privileges. It doesn't provide a way for stopping setuid on setuid binaries, though, and as we've previously noted, while we'd *like* to say that uids and privileges can be treated separately, in reality the unprivileged root user still owns most of the system. So we should also provide the per-task nosuid bit, meaning do not change uid for a setuid binary. This could be treated as another securebit, SECURE_NOSUID So if the capabilities module supports a special prctl(PR_SET_NOSUID) which at the same time completely empties pP, pE, pI, and the bounding set, and sets the SECURE_NOSUID securebit, that should be safe for an unprivileged user. (There is no need for SECURE_NOROOT and SECURE_NOSUIDFIXUP in that case obviously). Or, it could set SECURE_NOSUID|SECURE_NOROOT|SECURE_NOSUID_FIXUP (and the corresponding _LOCKED bits). -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Dolding on 31 Dec 2009 19:20 On Fri, Jan 1, 2010 at 3:06 AM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: >> Lets step back for a moment. �What is the common issue with both. >> >> The issue is simple. �"How to I generically tell the secuirty system >> want particular restrictions." > > You don't. It's not "the security system", its a whole collection of > completely different models of security and differing tools. > >> There is no generic LSM API for application or users to talk to the >> LSM and say I want the following restricted. > > That's a meaningless observation I think because security doesn't work > that way. Removing specific features from a specific piece of code > generally isn't a security feature - its only meaningful in the context > of a more general policy and that policy expression isn't generic. > Sandboxing it has meaning. The LSM section of the Linux secuirty system is out of reach of applications to talk to generically. They can use capabilities they can use DAC they can even talk generically to the firewall. >> To control the LSM the applications are expected to know what the LSM. >> �This has caused items like chrome major issues. > > .. > >> Application does not need to be informed what is disabled from it. > > So why does it cause chrome problems ? > > They were trying to create a sandbox inside there applications. > There are multiple security models because nobody can agree on what they > should look like, just like multiple desktops. Each of them is based on a > totally different conceptual model so the idea of a single interface to > them is a bit meaningless. > Bad argument flawed one and in breach of LSM API basic idea. All the secuirty modules are using generic hooks. All these patches are duplications of generic hooks because applications and users cannot control the generic hooks. All your answer is use the LSM because it already has the hook there. Problem is they cannot generically. So LSM is failing to make LSM generic enough for all requirements. The interface I am talking about does not give a rats about 90 percent of the secuirty module. So if they want completely different conceptual ideas there go for it. Generic is the following. Means for applications or users to say I don't want to use any off the following locations that LSM has hooks. Everything in the generic has to exist as LSM hooks. Now a generic LSM interface for applications and users the LSM is free to use the application and users provided data how they choose this include disregarding just like file capabilities can be disabled. API call is one way. Section in the ELF file is another ie elf having text data secuirty. The section design has to be LSM generic as well. Lets say a LSM does not have a profile for an application it sees that application comes with a secuirty section so is able to pick this up and use this as a rough profile. The generic is having nothing todo with role based secuirty controls or inheritance of permissions to be correct the LSM is free to apply those limitations over the top. In some cases an application declaring in advance what features they need could protect end users from data lose from LSM termination. Reason the application did not start in the first place. The biggest headache with setting up non standard LSM correctly is that applications have no way of declaring a list of what they need and don't need in a LSM generic way. Everything in the generic interfaces for users and applications would relate directly to the raw generic LSM hooks not to the security model being applied past that. This is not crossing into LSM turf. I don't want to be inside the LSM turf when coding inside an application and need to sandbox just need to tell the LSM that from here on must be restricted. Preferable in a way that is LSM generic. I don't want as a application design to having to create rules for every LSM in existance with verations for each distributions idea of role base secuirty and the like. Be truthful LSM hooks are a lot finer than capabilities and can cut a lot more things off from applications. Exactly what secuirty advantage is served by applications not being able to talk to the LSM module in a generic way? None that I know of. If there is some please tell me. But I can think of plenty that can be served by applications being able to talk to and provide generic information. 1) Simpler LSM configuration this is one of the biggest bug bears of LSM. 2) Less data loss from LSM configured wrong ie application being able to provide list of what it needs so admin does not restrict it too much. It might take months it use a feature that causes the LSM to terminate an application. 3) Sandboxing inside applications that works fairly simply for application developers. 4) Windows managers and the like able to provide users with options like networking on particular applications disabled on user demard in a generic way. Things that cannot always rewritten into policy. Some applications users will want to run different ways depending on what they are doing. Like you might want to run a download manager with networking disabled even that you are online because you are on a voip call and you don't want it starting up downloading stuff. 5) Anti-virus/Anti-malware being able to apply restrictions to items detected as suspect even if user decided to keep on running it in a generic way. 6) Option to reduce how much in LSM secuirty configuration data has to be LSM unique. If lets say LSMs would use a secuirty section in the elf data as part of there application config. Any alteration in the generic data would apply to all the LSM support it at once. Less duplication of data is better. Lower the duplication less risk of maintainer errors when updating LSM secuirty information. Of course providing all this not one removes the need for role based secuirty and the like over the top its in the role based secuiryt and the like where LSM want to fight. Let them lets just not cripple users secuirty control while in use just because those guys cannot get to a common design. Yes applying what I say might cause a higher level inside LSM's to become generic. This would be LSM completing it goals of being generic. It exists to encourage generic methods in the LSM modules. Peter Dolding -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 1 Jan 2010 05:30
> > Added bprm->nosuid to make remove the need to add > > duplicate error prone checks. This ensures that > > the disabling of suid executables is exactly the > > same as MNT_NOSUID. > > Another fine example of why we have security hooks so that we don't get a > kernel full of other "random security idea of the day" hacks. well... new unshare functionality depends on this. if unshare is important enough, this may not be lsm. (and disablenetwork *should* depend on this) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |