* Dropping SELinux privileges [not found] <3453b4110905151046s27022fb4jf9975fa4523572fa@mail.gmail.com> @ 2009-05-15 18:00 ` Sebastien Raveau 2009-05-15 18:33 ` Joshua Brindle 0 siblings, 1 reply; 4+ messages in thread From: Sebastien Raveau @ 2009-05-15 18:00 UTC (permalink / raw) To: SELinux Hi everybody! As a personal challenge I am trying to reach "state of the art" security on my home router... and for that I'm using SELinux of course ;-) I have everything setup and working, but what intrigues me is: isn't there a way to drop SELinux privileges? I mean, many programs require privileges only during their startup phase, and restricting their rights from the outside proves impossible; that's why volontary chroot(), setgid() and setuid() are so useful: the program decides when to relinquish its privileges. For example, a program like OpenVPN should only be allowed network I/O, but because its initialization invokes shell commands, we have to give it many more rights than it actually needs. Granted, in the case of OpenVPN the combination with setuid and chroot solves the shell commands problem, but this still makes policy files too complex... Maximum (theoretical) security could be reached if a program could be allowed to switch from some policy to an even more restrictive policy, and very simple policy files could be written if a program could be allowed to start unconfined and when ready apply a policy to itself, which is basically the same. I couldn't find such a thing in the SELinux API: have I misread? Or it does not exist and perhaps I could contribute it? :-) Best regards, -- Sebastien Raveau -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dropping SELinux privileges 2009-05-15 18:00 ` Dropping SELinux privileges Sebastien Raveau @ 2009-05-15 18:33 ` Joshua Brindle 2009-05-18 8:53 ` selinux 0 siblings, 1 reply; 4+ messages in thread From: Joshua Brindle @ 2009-05-15 18:33 UTC (permalink / raw) To: Sebastien Raveau; +Cc: SELinux Sebastien Raveau wrote: > Hi everybody! > > > As a personal challenge I am trying to reach "state of the art" > security on my home router... and for that I'm using SELinux of course > ;-) > > I have everything setup and working, but what intrigues me is: isn't > there a way to drop SELinux privileges? > > I mean, many programs require privileges only during their startup > phase, and restricting their rights from the outside proves > impossible; that's why volontary chroot(), setgid() and setuid() are > so useful: the program decides when to relinquish its privileges. > > For example, a program like OpenVPN should only be allowed network > I/O, but because its initialization invokes shell commands, we have to > give it many more rights than it actually needs. Granted, in the case > of OpenVPN the combination with setuid and chroot solves the shell > commands problem, but this still makes policy files too complex... > > Maximum (theoretical) security could be reached if a program could be > allowed to switch from some policy to an even more restrictive policy, > and very simple policy files could be written if a program could be > allowed to start unconfined and when ready apply a policy to itself, > which is basically the same. > > > I couldn't find such a thing in the SELinux API: have I misread? Or it > does not exist and perhaps I could contribute it? :-) > > Best regards, > SELinux has a concept of type transitions to change the type (or domain) of a process over an exec(). So the openvpn example would type transition when it runs the shell commands and the shell commands would run in a less privileged domain. There is also a way to change the domain of a process at runtime called setcon() though we prefer transitions over exec() because they can be enforced and less state is passed over exec than available in a running process. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dropping SELinux privileges 2009-05-15 18:33 ` Joshua Brindle @ 2009-05-18 8:53 ` selinux 2009-05-18 12:35 ` Stephen Smalley 0 siblings, 1 reply; 4+ messages in thread From: selinux @ 2009-05-18 8:53 UTC (permalink / raw) To: Joshua Brindle; +Cc: SELinux On Fri, May 15, 2009 at 02:33:29PM -0400, Joshua Brindle wrote: > Sebastien Raveau wrote: >> Hi everybody! >> >> >> As a personal challenge I am trying to reach "state of the art" >> security on my home router... and for that I'm using SELinux of course >> ;-) >> >> I have everything setup and working, but what intrigues me is: isn't >> there a way to drop SELinux privileges? >> >> I mean, many programs require privileges only during their startup >> phase, and restricting their rights from the outside proves >> impossible; that's why volontary chroot(), setgid() and setuid() are >> so useful: the program decides when to relinquish its privileges. >> >> For example, a program like OpenVPN should only be allowed network >> I/O, but because its initialization invokes shell commands, we have to >> give it many more rights than it actually needs. Granted, in the case >> of OpenVPN the combination with setuid and chroot solves the shell >> commands problem, but this still makes policy files too complex... >> >> Maximum (theoretical) security could be reached if a program could be >> allowed to switch from some policy to an even more restrictive policy, >> and very simple policy files could be written if a program could be >> allowed to start unconfined and when ready apply a policy to itself, >> which is basically the same. >> >> >> I couldn't find such a thing in the SELinux API: have I misread? Or it >> does not exist and perhaps I could contribute it? :-) >> >> Best regards, >> > > SELinux has a concept of type transitions to change the type (or domain) > of a process over an exec(). So the openvpn example would type transition > when it runs the shell commands and the shell commands would run in a > less privileged domain. > > There is also a way to change the domain of a process at runtime called > setcon() though we prefer transitions over exec() because they can be > enforced and less state is passed over exec than available in a running > process. By the way, why there is no type transition on fork? It would help a lot on confining traditional unix services with minimum effort, don't you think? Everybody knows that there is some common model - parent is listener, children are workers, but all code resides in one binary. Splitting it into separate programs requires some effort, you know. One extra file in /proc will easily help to "convert" such applications to SELinux. You will have to just change the starup script: after parent is started you just write to /proc file the required children's context (assuming it is the same across all forks), and that's it, no extra patches to application is needed, no recompilation. Isn't it easy and robust solution? Am I wrong or what? Or maybe such thing already present somewhere? > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with > the words "unsubscribe selinux" without quotes as the message. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Dropping SELinux privileges 2009-05-18 8:53 ` selinux @ 2009-05-18 12:35 ` Stephen Smalley 0 siblings, 0 replies; 4+ messages in thread From: Stephen Smalley @ 2009-05-18 12:35 UTC (permalink / raw) To: selinux; +Cc: Joshua Brindle, SELinux On Mon, 2009-05-18 at 13:53 +0500, selinux@udmvt.ru wrote: > On Fri, May 15, 2009 at 02:33:29PM -0400, Joshua Brindle wrote: > > Sebastien Raveau wrote: > >> Hi everybody! > >> > >> > >> As a personal challenge I am trying to reach "state of the art" > >> security on my home router... and for that I'm using SELinux of course > >> ;-) > >> > >> I have everything setup and working, but what intrigues me is: isn't > >> there a way to drop SELinux privileges? > >> > >> I mean, many programs require privileges only during their startup > >> phase, and restricting their rights from the outside proves > >> impossible; that's why volontary chroot(), setgid() and setuid() are > >> so useful: the program decides when to relinquish its privileges. > >> > >> For example, a program like OpenVPN should only be allowed network > >> I/O, but because its initialization invokes shell commands, we have to > >> give it many more rights than it actually needs. Granted, in the case > >> of OpenVPN the combination with setuid and chroot solves the shell > >> commands problem, but this still makes policy files too complex... > >> > >> Maximum (theoretical) security could be reached if a program could be > >> allowed to switch from some policy to an even more restrictive policy, > >> and very simple policy files could be written if a program could be > >> allowed to start unconfined and when ready apply a policy to itself, > >> which is basically the same. > >> > >> > >> I couldn't find such a thing in the SELinux API: have I misread? Or it > >> does not exist and perhaps I could contribute it? :-) > >> > >> Best regards, > >> > > > > SELinux has a concept of type transitions to change the type (or domain) > > of a process over an exec(). So the openvpn example would type transition > > when it runs the shell commands and the shell commands would run in a > > less privileged domain. > > > > There is also a way to change the domain of a process at runtime called > > setcon() though we prefer transitions over exec() because they can be > > enforced and less state is passed over exec than available in a running > > process. > By the way, why there is no type transition on fork? It would help a lot > on confining traditional unix services with minimum effort, don't you think? > Everybody knows that there is some common model - parent is listener, children > are workers, but all code resides in one binary. Splitting it into separate > programs requires some effort, you know. One extra file in /proc will easily > help to "convert" such applications to SELinux. > You will have to just change the starup script: after parent is started you just write > to /proc file the required children's context (assuming it is the same across all forks), > and that's it, no extra patches to application is needed, no recompilation. > Isn't it easy and robust solution? Am I wrong or what? > Or maybe such thing already present somewhere? Prior discussion of fork and security context transitions: http://marc.info/?t=107545401000002&r=1&w=2 This is partly obsoleted by the introduction of setcon(3), which does allow dynamic context transitions (but comes with strong caveats about its use - effectively only appropriate when the program is trusted to maintain separation between the two contexts). However, the program would still need to be modified to invoke setcon(3) after the fork(). Even aside from lack of separation, since the kernel cannot distinguish the purpose of the fork() call from any other fork() call made by the application, I doubt automatic type transitions on fork would in fact be useful, and they seem very prone to error. With regard to setting the security attributes of one process from another process (since you indicated that you would write to the /proc file from the startup script rather than modify the program), that is decidedly racy and unsafe, and likewise very prone to error. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-05-18 12:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <3453b4110905151046s27022fb4jf9975fa4523572fa@mail.gmail.com>
2009-05-15 18:00 ` Dropping SELinux privileges Sebastien Raveau
2009-05-15 18:33 ` Joshua Brindle
2009-05-18 8:53 ` selinux
2009-05-18 12:35 ` Stephen Smalley
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.