ppp

ppp

[Ryan Raasch]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

Hello,

We need a ppp interface for our modem. I was told on the chat forum that 
a tap/tun device was to be used. Has anyone else started with this or 
thought how to implement this?

After reading briefly the code from pppd, the implementation, for a 
first draft, is pretty straight forward (w/o encryption, etc. in 
userspace). "Just" dial the apn, and hand over the tty fd to ppp via ioctl.

Steps (borrowed from pppd):

1. Dial the apn (in ofonod).
2. Some synchronization code.
3. hand over tty fd to ppp driver via ioctl. the IP.

I know i am simplifying the process.

Is this the way to go?


Regards,
Ryan

Re: ppp

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Hi Ryan,

> Hello,
>
> We need a ppp interface for our modem. I was told on the chat forum that
> a tap/tun device was to be used. Has anyone else started with this or
> thought how to implement this?

We're currently working on a userspace ppp implementation that will integrate 
with GAtChat.  The goal here is to make it integrate well with the current 
multiplexed channel capability in GAtMux/GatChat and not need to involve an 
external daemon.

>
> After reading briefly the code from pppd, the implementation, for a
> first draft, is pretty straight forward (w/o encryption, etc. in
> userspace). "Just" dial the apn, and hand over the tty fd to ppp via ioctl.
>

Unfortunately it is not that simple.  pppd requires a proper kernel file 
descriptor to hand off to the kernel ppp line discipline.  In our userspace 
implementation that is not the case.  1 kernel file descriptor is shared by 
potentially many GAtChat channels using a multiplexing protocol.  Hence why we 
can't reuse the kernel implementation.

Regards,
-Denis

Re: ppp

[Ryan Raasch]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]



Denis Kenzior wrote:
> Hi Ryan,
> 
>> Hello,
>>
>> We need a ppp interface for our modem. I was told on the chat forum that
>> a tap/tun device was to be used. Has anyone else started with this or
>> thought how to implement this?
> 
> We're currently working on a userspace ppp implementation that will integrate 
> with GAtChat.  The goal here is to make it integrate well with the current 
> multiplexed channel capability in GAtMux/GatChat and not need to involve an 
> external daemon.
> 

Wow. So ofono will not use the kernel space ppp and implement the ppp 
stack in userspace?

>> After reading briefly the code from pppd, the implementation, for a
>> first draft, is pretty straight forward (w/o encryption, etc. in
>> userspace). "Just" dial the apn, and hand over the tty fd to ppp via ioctl.
>>
> 
> Unfortunately it is not that simple.  pppd requires a proper kernel file 
> descriptor to hand off to the kernel ppp line discipline.  In our userspace 
> implementation that is not the case.  1 kernel file descriptor is shared by 
> potentially many GAtChat channels using a multiplexing protocol.  Hence why we 
> can't reuse the kernel implementation.
> 

Yea. That's right.

> Regards,
> -Denis
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono

Re: ppp

[Chris Pitchford]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]


On Thu, 12 Nov 2009, Denis Kenzior wrote:

>
> Unfortunately it is not that simple.  pppd requires a proper kernel file
> descriptor to hand off to the kernel ppp line discipline.  In our userspace
> implementation that is not the case.  1 kernel file descriptor is shared by
> potentially many GAtChat channels using a multiplexing protocol.  Hence why we
> can't reuse the kernel implementation.
>

Not sure how relevant this is, but many many years ago (1997) I used a 
"telnet modem" to circumvent a firewall. It was a user land process that 
presented a fake /dev/modem which I used using pppd and chat..

My machine was behind a firewall with a telnet proxy.. Using the software 
+ pppd + chat, it was set up along the lines:

start telnet modem which presented a /dev/modem.. start pppd using 
/dev/modem:

ATDT 1.2.3.4
CONNECT 1.2.3.4
the-telnet-proxy>
telnet my.host 23
connected to my.host:23
login:
mypppuser
password:
mypassword
end of chat script... start pppd

In this situation, pppd and the kernel device would have been 
communicating with a local userland process. The TCP connection to 1.2.3.4 
created by the telnet modem could not have been used by the ppp interface 
as the telnet modem was passing the streams in either direction 
essentially joining the fd of the telnet connection and fd used by pppd..

I'm not sure if the requirements of ppp in the kernel have chagned, but 
couldn't something like this be repeated in this situation.. allowing pppd 
to speak to a local socket/fifo/pair of pipes that is terminated in user 
space?

I'll see if I can drag the code out to see what it actually did.. and 
even better see if I can get it to work on a 2.6 kernel!!

Re: ppp

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]


On Thu, 12 Nov 2009 19:39:40 +0000 (GMT), Chris Pitchford
<ofono@intrepid.cx> wrote:
> I'm not sure if the requirements of ppp in the kernel have chagned, but
> couldn't something like this be repeated in this situation.. allowing
pppd
> to speak to a local socket/fifo/pair of pipes that is terminated in user
> space?

In my understanding, PPP is a line discipline, meaning it can only run on a
TTY character device device, not just any character device, and definitely
not any random file descriptor.

-- 
Rémi Denis-Courmont

Re: ppp

[Chris Pitchford]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]


Quoting Rémi Denis-Courmont <remi@remlab.net>:

>
> On Thu, 12 Nov 2009 19:39:40 +0000 (GMT), Chris Pitchford
> <ofono@intrepid.cx> wrote:
>> I'm not sure if the requirements of ppp in the kernel have chagned, but
>> couldn't something like this be repeated in this situation.. allowing
> pppd
>> to speak to a local socket/fifo/pair of pipes that is terminated in user
>> space?
>
> In my understanding, PPP is a line discipline, meaning it can only run on a
> TTY character device device, not just any character device, and definitely
> not any random file descriptor.

turns out that the software I mentioned (virtmodem from 1995) does  
indeed use a pty pair. Although I've not had time during the week to  
get it running again, I suspect it would probably work on a recent  
kernel/pppd.

Is the line discipline so much of an issue when using ppp connected to  
a fake tty? could that not be handed on the proxy side inside ofono?

Re: ppp

[Andrzej Zaborowski]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Hi,

2009/11/13 Chris Pitchford <ofono@intrepid.cx>:
> Is the line discipline so much of an issue when using ppp connected to a
> fake tty? could that not be handed on the proxy side inside ofono?

I've not tried it on a non-tty but it definitely should work modulo
potential bugs that need to be squashed.  It's supposed to work.

However by using a separate process to do ppp you add overhead.  The
original idea in ofono as well as in other projects (think OpenMoko)
was to have both ppp and multiplexing in the kernel to avoid the
context switches when a lot of data is being sent, but this is not
very portable and causes lots of other problems.  Having both in a
single non-kernel process is going to be almost as fast and much more
portable at the expense of reimplementing part of pppd.

Regards

Re: ppp

[Chris Pitchford]

[-- Attachment #1: Type: text/plain, Size: 2878 bytes --]


> Hi,
>
> 2009/11/13 Chris Pitchford <ofono@intrepid.cx>:
>> Is the line discipline so much of an issue when using ppp connected to a
>> fake tty? could that not be handed on the proxy side inside ofono?
>
> I've not tried it on a non-tty but it definitely should work modulo
> potential bugs that need to be squashed.  It's supposed to work.
>
> However by using a separate process to do ppp you add overhead.  The
> original idea in ofono as well as in other projects (think OpenMoko)
> was to have both ppp and multiplexing in the kernel to avoid the
> context switches when a lot of data is being sent, but this is not
> very portable and causes lots of other problems.  Having both in a
> single non-kernel process is going to be almost as fast and much more
> portable at the expense of reimplementing part of pppd.
>

I've had another thought.. and it doesn't push for pppd, but it introduces 
another idea.

When connecting to an APN for MMS services, there is the possibility of a 
clash of IP addresses both with other APN connections and with other 
internet connections (for example wifi)..


For example: wlan0 192.168.1.20/24 default gw 192.168.1.250

ppp0/tun0: 10.1.1.1 <=> 10.255.255.255

and the MMSC (to which the phone will need to communicate to send/receive 
MMS) is 192.168.1.20

bam.. it clashes with a locally assigned IP address and therefore no 
policy routing will allow a process to reach 192.168.1.20 via the MMS 
interface (or atleast not with excessive engineering)

Other clashes may cause problems too..

To solve the problem, the MMS environment could be run in its own kernel 
network name space. This means the ppp/tun interface would be separate 
from the other interfaces.. this removes the clashing IP address space 
problem.

If pppd were used, it could be "wrapped" in a different address space 
meaning the ppp interface would be localised to an environment that 
carried out all of the MMS communications. What's more, the work would 
require no change to the existing global address space.. it very neatly 
keeps the main environment seperate from the MMS environment that requires 
its own gateway and IP address space..

I appreciate the chances of a clash are slim, but with telcos using 
RFC-1918 and home users mainly using the same the chances of a clash are 
far above zero (and I hear it is a problem for iphone users.. no dig at 
iphones but a colleage reports seeing MMS traffic over his wireless 
connection.. not confirmed but still)

So, if ofonod is responsible for creating tun interfaces, I'm not sure it 
would be possible to isolate them within their own name space and 
therefore allow concurrent "internet" and "mms" access via two different 
connections..

I'm still formulating my thoughts on this one, but I hope it is food for 
thought!

cp

Re: ppp

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

Le samedi 14 novembre 2009 21:26:38 Chris Pitchford, vous avez écrit :
> When connecting to an APN for MMS services, there is the possibility of a
> clash of IP addresses both with other APN connections and with other
> internet connections (for example wifi)..

You'd have to implement TCP/IP in userspace also, which wouldn't be too nice. 
With recent kernels (2.6.29 and up), you'd rather want to create a new network 
kernel namespace, containing the MMS interface and the one or few processes 
sending or receiving MMS.

That avoids the IP range conflicts while not needing to reimplement TCP/IP. It 
also still works if the modem exposes GPRS through sone kernel driver such 
that you cannot cleanly send and receive IP packets in userspace anyway. 
Currently, there aren't any in oFono, as both PPP and Phonet can provide IP 
packets to userspace. But that does not mean there won't ever be any.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

Re: ppp

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

Hi Chris,

> > Unfortunately it is not that simple.  pppd requires a proper kernel file
> > descriptor to hand off to the kernel ppp line discipline.  In our userspace
> > implementation that is not the case.  1 kernel file descriptor is shared by
> > potentially many GAtChat channels using a multiplexing protocol.  Hence why we
> > can't reuse the kernel implementation.
> >
> 
> Not sure how relevant this is, but many many years ago (1997) I used a 
> "telnet modem" to circumvent a firewall. It was a user land process that 
> presented a fake /dev/modem which I used using pppd and chat..
> 
> My machine was behind a firewall with a telnet proxy.. Using the software 
> + pppd + chat, it was set up along the lines:
> 
> start telnet modem which presented a /dev/modem.. start pppd using 
> /dev/modem:
> 
> ATDT 1.2.3.4
> CONNECT 1.2.3.4
> the-telnet-proxy>
> telnet my.host 23
> connected to my.host:23
> login:
> mypppuser
> password:
> mypassword
> end of chat script... start pppd
> 
> In this situation, pppd and the kernel device would have been 
> communicating with a local userland process. The TCP connection to 1.2.3.4 
> created by the telnet modem could not have been used by the ppp interface 
> as the telnet modem was passing the streams in either direction 
> essentially joining the fd of the telnet connection and fd used by pppd..
> 
> I'm not sure if the requirements of ppp in the kernel have chagned, but 
> couldn't something like this be repeated in this situation.. allowing pppd 
> to speak to a local socket/fifo/pair of pipes that is terminated in user 
> space?

yes we could do that, but why bother with a PTY to push the data packets
into the kernel. At that point we can also run PPP in userspace and use
a TUN/TAP device to create our network interface. The question is when
do we wanna move the data from userspace into the kernel.

Also pppd does the whole setup of PPP session. The ppp_generic in the
kernel only das the data packets transport. Meaning the PPP session
setup needs to be done in userspace anyway.

Regards

Marcel

Re: ppp

[Chris Pitchford]

[-- Attachment #1: Type: text/plain, Size: 3006 bytes --]


Quoting Marcel Holtmann <marcel@holtmann.org>:

> Hi Chris,
>
>> > Unfortunately it is not that simple.  pppd requires a proper kernel file
>> > descriptor to hand off to the kernel ppp line discipline.  In our  
>> userspace
>> > implementation that is not the case.  1 kernel file descriptor is  
>> shared by
>> > potentially many GAtChat channels using a multiplexing protocol.   
>> Hence why we
>> > can't reuse the kernel implementation.
>> >
>>
>> Not sure how relevant this is, but many many years ago (1997) I used a
>> "telnet modem" to circumvent a firewall. It was a user land process that
>> presented a fake /dev/modem which I used using pppd and chat..
>>
>> My machine was behind a firewall with a telnet proxy.. Using the software
>> + pppd + chat, it was set up along the lines:
>>
>> start telnet modem which presented a /dev/modem.. start pppd using
>> /dev/modem:
>>
>> ATDT 1.2.3.4
>> CONNECT 1.2.3.4
>> the-telnet-proxy>
>> telnet my.host 23
>> connected to my.host:23
>> login:
>> mypppuser
>> password:
>> mypassword
>> end of chat script... start pppd
>>
>> In this situation, pppd and the kernel device would have been
>> communicating with a local userland process. The TCP connection to 1.2.3.4
>> created by the telnet modem could not have been used by the ppp interface
>> as the telnet modem was passing the streams in either direction
>> essentially joining the fd of the telnet connection and fd used by pppd..
>>
>> I'm not sure if the requirements of ppp in the kernel have chagned, but
>> couldn't something like this be repeated in this situation.. allowing pppd
>> to speak to a local socket/fifo/pair of pipes that is terminated in user
>> space?
>
> yes we could do that, but why bother with a PTY to push the data packets
> into the kernel. At that point we can also run PPP in userspace and use
> a TUN/TAP device to create our network interface. The question is when
> do we wanna move the data from userspace into the kernel.
>
> Also pppd does the whole setup of PPP session. The ppp_generic in the
> kernel only das the data packets transport. Meaning the PPP session
> setup needs to be done in userspace anyway.
>
> Regards
>

I understand your point about the setup being done in user space, but  
would it not be faster to present a vanilla pppd with a pty and allow  
it to setup the connection and pass data to the kernel interface  
rather than providing a new implementation? I mean from the point of  
view of reusing software that is already available and very well tested?

On the down side I see the "eeeew" factor of creating a pty pair just  
to pass data about, but if it means that far less code needs to be  
written (and much less code that is to interpret line traffic) I  
thought it might be safer solution. For example, if pppd is used, it  
already supports a wealth of authentication and feature negotiation.

I guess there are downsides to both approaches..

Re: ppp

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3583 bytes --]

Hi Chris,

> >> > Unfortunately it is not that simple.  pppd requires a proper kernel file
> >> > descriptor to hand off to the kernel ppp line discipline.  In our  
> >> userspace
> >> > implementation that is not the case.  1 kernel file descriptor is  
> >> shared by
> >> > potentially many GAtChat channels using a multiplexing protocol.   
> >> Hence why we
> >> > can't reuse the kernel implementation.
> >> >
> >>
> >> Not sure how relevant this is, but many many years ago (1997) I used a
> >> "telnet modem" to circumvent a firewall. It was a user land process that
> >> presented a fake /dev/modem which I used using pppd and chat..
> >>
> >> My machine was behind a firewall with a telnet proxy.. Using the software
> >> + pppd + chat, it was set up along the lines:
> >>
> >> start telnet modem which presented a /dev/modem.. start pppd using
> >> /dev/modem:
> >>
> >> ATDT 1.2.3.4
> >> CONNECT 1.2.3.4
> >> the-telnet-proxy>
> >> telnet my.host 23
> >> connected to my.host:23
> >> login:
> >> mypppuser
> >> password:
> >> mypassword
> >> end of chat script... start pppd
> >>
> >> In this situation, pppd and the kernel device would have been
> >> communicating with a local userland process. The TCP connection to 1.2.3.4
> >> created by the telnet modem could not have been used by the ppp interface
> >> as the telnet modem was passing the streams in either direction
> >> essentially joining the fd of the telnet connection and fd used by pppd..
> >>
> >> I'm not sure if the requirements of ppp in the kernel have chagned, but
> >> couldn't something like this be repeated in this situation.. allowing pppd
> >> to speak to a local socket/fifo/pair of pipes that is terminated in user
> >> space?
> >
> > yes we could do that, but why bother with a PTY to push the data packets
> > into the kernel. At that point we can also run PPP in userspace and use
> > a TUN/TAP device to create our network interface. The question is when
> > do we wanna move the data from userspace into the kernel.
> >
> > Also pppd does the whole setup of PPP session. The ppp_generic in the
> > kernel only das the data packets transport. Meaning the PPP session
> > setup needs to be done in userspace anyway.
> >
> 
> I understand your point about the setup being done in user space, but  
> would it not be faster to present a vanilla pppd with a pty and allow  
> it to setup the connection and pass data to the kernel interface  
> rather than providing a new implementation? I mean from the point of  
> view of reusing software that is already available and very well tested?

if you look at the pppd code and tell us how to control it properly from
within another daemon, then we can talk. That is just stupid to the end
and would require massive extension of pppd. Also it ends up setting IP,
routing and DNS details and some other magic. It works as a quick hack,
but in the long run needs to be replaced.

> On the down side I see the "eeeew" factor of creating a pty pair just  
> to pass data about, but if it means that far less code needs to be  
> written (and much less code that is to interpret line traffic) I  
> thought it might be safer solution. For example, if pppd is used, it  
> already supports a wealth of authentication and feature negotiation.

And the authentication etc. is not really that much with GSM cards. They
are fairly limited in what they support. Especially since PPP only run
between the card and the host. It doesn't go over the network.

Regards

Marcel

Re: ppp

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]


On Thu, 12 Nov 2009 12:37:30 -0600, Denis Kenzior <denkenz@gmail.com>
wrote:
> Unfortunately it is not that simple.  pppd requires a proper kernel file
> descriptor to hand off to the kernel ppp line discipline.  In our
> userspace implementation that is not the case.  1 kernel file descriptor
> is shared by potentially many GAtChat channels using a multiplexing
> protocol. 

You _could_ create a PTS/PTY pair though...

> Hence why we can't reuse the kernel implementation.

...But I am not sure if the PPP line discipline works correctly on top of
/dev/pts.

-- 
Rémi Denis-Courmont

PPP

[Pooja Nagpal]

Hi!

Sorry for the slow replies!

I had something like interrupts(like Blaz Antonic suggested) in mind instead of polling. 

I was also wondering what would happen if packets came in faster than we can process. Will i lose
the packets.When I tested the PPP code in Linux before trying it on ELKS, I somehow seemed to be
getting empty frames etc. The same code when complied for ELKS worked fine. I am not sure what the
problem was. 

I don't think the options negotiated in the LCP are 'do and forget'. I think the link properties
need to stored. pppd could just negotiate options, store and exit. The network layer specific NCP
could then take over but I am not sure where it goes. If its in the kernel, how should i go about
it?

Thanks,
Pooja

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

Re: PPP

[Harry Kalogirou]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

> Hi!
> 
> Sorry for the slow replies!
> 
> I had something like interrupts(like Blaz Antonic suggested) in mind instead of polling. 
> 
> I was also wondering what would happen if packets came in faster than we can process. Will i lose
> the packets.When I tested the PPP code in Linux before trying it on ELKS, I somehow seemed to be
> getting empty frames etc. The same code when complied for ELKS worked fine. I am not sure what the
> problem was. 
> 
> I don't think the options negotiated in the LCP are 'do and forget'. I think the link properties
> need to stored. pppd could just negotiate options, store and exit. The network layer specific NCP
> could then take over but I am not sure where it goes. If its in the kernel, how should i go about
> it?
> 
> Thanks,
> Pooja
> 

I just had a glance to the PPP rfc and it seems that in order to have a
functional PPP, LCP NCP packets should be interpretted all times. The
straightforward way of doing it is to have a pppd demon reading the
packets from the serial line doing the processing and passing it to the
above layer. For ipv4 in ELKS this means passing them to the ktcp demon.
This passing is that conserns me. This will probably be done throught a
UNIX socket. So for a process to get it's data we need many many task
switches and data copying(kernel -> pppd -> kernel -> ktcp -> kernel ->
process). So it is probably better for the PPP code and ipv6 code to be
added in ktcp.

Harry






[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

ppp

[Russell Coker]

It is common to install pppd in such a fashion that it can be run as 
"pppd call server" by a regular user.

The problem is that it often starts daemons from it's ip-up script once it 
connects, and such daemons aren't allowed to be in user_r!

I notice that the policy directive for doing an automatic role transition is 
now deprecated.

I am thinking of writing a pppd wrapper program which runs it as 
"system_u:system_r:pppd_t", what do you think?

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: ppp

[John Summerfield]

> It is common to install pppd in such a fashion that it can be run as 
> "pppd call server" by a regular user.
> 
> The problem is that it often starts daemons from it's ip-up script once it 
> connects, and such daemons aren't allowed to be in user_r!
> 
> I notice that the policy directive for doing an automatic role transition is 
> now deprecated.
> 
> I am thinking of writing a pppd wrapper program which runs it as 
> "system_u:system_r:pppd_t", what do you think?


There is a wrapper in Red Hat Linux. Look for usernetctl

-- 
Cheers
John Summerfield

Microsoft's most solid OS: http://www.geocities.com/rcwoolley/

Note: mail delivered to me is deemed to be intended for me, for my disposition.

==============================
If you don't like being told you're wrong,
	be right!




--
You have received this message because you are subscribed to the selinux 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.

Re: ppp

[Russell Coker]

On Tue, 7 May 2002 13:43, John Summerfield wrote:
> > It is common to install pppd in such a fashion that it can be run as
> > "pppd call server" by a regular user.
> >
> > The problem is that it often starts daemons from it's ip-up script once
> > it connects, and such daemons aren't allowed to be in user_r!
> >
> > I notice that the policy directive for doing an automatic role transition
> > is now deprecated.
> >
> > I am thinking of writing a pppd wrapper program which runs it as
> > "system_u:system_r:pppd_t", what do you think?
>
> There is a wrapper in Red Hat Linux. Look for usernetctl

I am not after a wrapper for the connect/disconnect functionality, I think 
that the pon/poff scripts from Debian are good enough (and probably better 
than the Red Hat equivalents).

I am talking about something similar to run_init but without a password 
prompt, which is why I'm asking here as this may considered a bad idea for 
security...

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: ppp

[Stephen Smalley]

On Tue, 7 May 2002, Russell Coker wrote:

> It is common to install pppd in such a fashion that it can be run as
> "pppd call server" by a regular user.
>
> The problem is that it often starts daemons from it's ip-up script once it
> connects, and such daemons aren't allowed to be in user_r!
>
> I am thinking of writing a pppd wrapper program which runs it as
> "system_u:system_r:pppd_t", what do you think?

I suppose that the question is whether we obtain any real security benefit
from having such a wrapper vs. directly authorizing user_r for the
necessary domains and directly authorizing user_t to transition via
pppd_exec_t to pppd_t.  The domain transitions would still be limited
based on the entrypoint program.  Can you clarify exactly what other
daemons might be started in this manner?

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux 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.

Re: ppp

[Russell Coker]

On Wed, 8 May 2002 00:22, Stephen Smalley wrote:
> > It is common to install pppd in such a fashion that it can be run as
> > "pppd call server" by a regular user.
> >
> > The problem is that it often starts daemons from it's ip-up script once
> > it connects, and such daemons aren't allowed to be in user_r!
> >
> > I am thinking of writing a pppd wrapper program which runs it as
> > "system_u:system_r:pppd_t", what do you think?
>
> I suppose that the question is whether we obtain any real security benefit
> from having such a wrapper vs. directly authorizing user_r for the
> necessary domains and directly authorizing user_t to transition via
> pppd_exec_t to pppd_t.  The domain transitions would still be limited
> based on the entrypoint program.  Can you clarify exactly what other
> daemons might be started in this manner?

In my policy I already have a user_t transition to pppd_t.  The issue is that 
pppd should not be running in user_r because the ip-up scripts will start 
other daemons which should be in domains that aren't permitted in user_r (EG 
the mail server).

Basically preserving the current mode of operation of pppd for manual 
call-out and keeping it in user_r means removing system_r because most things 
that belong in system_r will end up in user_r!

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: ppp

[Stephen Smalley]

On Wed, 8 May 2002, Russell Coker wrote:

> In my policy I already have a user_t transition to pppd_t.  The issue is that
> pppd should not be running in user_r because the ip-up scripts will start
> other daemons which should be in domains that aren't permitted in user_r (EG
> the mail server).
>
> Basically preserving the current mode of operation of pppd for manual
> call-out and keeping it in user_r means removing system_r because most things
> that belong in system_r will end up in user_r!

Right.  But it isn't clear that creating a wrapper as you suggested offers
any real security benefit in this situation, and it may simply obscure the
fact that the user_r/system_r role separation would then be illusory.  You
might as well just add all of the system_r domains into user_r.  In either
case, the TE model provides the real control over transitions and
interactions among user and system processes based on their domains.

In general, the RBAC model provides no improvement in security over the TE
model, just a higher level of abstraction to ease user management.  It can
potentially bound the set of domains that are reachable based on the
role (as long as role transitions are not completely unconstrained, as it
appears that they are becoming), but the same effect can be achieved
simply by controlling domain transitions and defining derived domains as
necessary to maintain separation.  If role transitions will typically be
unconstrained, then one might argue that roles and the RBAC logic should
be removed entirely to avoid confusing the security model.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com












--
You have received this message because you are subscribed to the selinux 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.

Re: ppp

[Russell Coker]

On Wed, 8 May 2002 23:13, Stephen Smalley wrote:
> > In my policy I already have a user_t transition to pppd_t.  The issue is
> > that pppd should not be running in user_r because the ip-up scripts will
> > start other daemons which should be in domains that aren't permitted in
> > user_r (EG the mail server).
> >
> > Basically preserving the current mode of operation of pppd for manual
> > call-out and keeping it in user_r means removing system_r because most
> > things that belong in system_r will end up in user_r!
>
> Right.  But it isn't clear that creating a wrapper as you suggested offers
> any real security benefit in this situation, and it may simply obscure the
> fact that the user_r/system_r role separation would then be illusory.  You

No it would not be illusory!  It would be that there would be two ways of 
entering system_r, one of which is run_init (by the system administrator) and 
the other is the ppp wrapper which can be called by a user.

> might as well just add all of the system_r domains into user_r.  In either
> case, the TE model provides the real control over transitions and
> interactions among user and system processes based on their domains.

I don't like the idea of moving all the system_r domains into user_r.

> In general, the RBAC model provides no improvement in security over the TE
> model, just a higher level of abstraction to ease user management.  It can
> potentially bound the set of domains that are reachable based on the
> role (as long as role transitions are not completely unconstrained, as it
> appears that they are becoming), but the same effect can be achieved
> simply by controlling domain transitions and defining derived domains as
> necessary to maintain separation.  If role transitions will typically be
> unconstrained, then one might argue that roles and the RBAC logic should
> be removed entirely to avoid confusing the security model.

I take your point, however I am definately not proposing totally 
uncontstrained role transitions.  I am merely suggesting a wrapper program to 
solve one particular instance of role transitions.

How else should we approach this problem?  I guess I could have a pppd which 
is always running, and have a SUID-root helper program which tells it when to 
connect or disconnect.  Then the helper program would only need permissions 
to send signals or write to a Unix domain socket.  I can get this done (I 
have commit access to the PPP CVS) if it's considered the right thing to do, 
although it will take time.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: ppp

[Stephen Smalley]

On Thu, 9 May 2002, Russell Coker wrote:

> No it would not be illusory!  It would be that there would be two ways of
> entering system_r, one of which is run_init (by the system administrator) and
> the other is the ppp wrapper which can be called by a user.

Except that the wrapper does nothing other than to run pppd in
system_u:system_r:pppd_t.  Hence, every user_r process can transition to
system_r.  The corresponding program (pppd) and domain (pppd_t) would be
hardcoded by the wrapper (and could be strictly enforced by the TE model -
i.e. the wrapper domain can be limited to running pppd in pppd_t), but the
role separation itself would be gone.

> I don't like the idea of moving all the system_r domains into user_r.

Understood, but keep in mind that the end result is the same.  Even if you
place all of the system_r domains into user_r, that doesn't mean that a
user_r:user_t process can transition (directly) to those domains.  The TE
policy controls the domain transitions and entrypoint programs, so you can
simply authorize user_t to run pppd in pppd_t and authorize pppd_t to run
the daemon programs in their domains.

> I take your point, however I am definately not proposing totally
> uncontstrained role transitions.  I am merely suggesting a wrapper program to
> solve one particular instance of role transitions.
>
> How else should we approach this problem?  I guess I could have a pppd which
> is always running, and have a SUID-root helper program which tells it when to
> connect or disconnect.  Then the helper program would only need permissions
> to send signals or write to a Unix domain socket.  I can get this done (I
> have commit access to the PPP CVS) if it's considered the right thing to do,
> although it will take time.

In the short term, the ppp wrapper is probably fine.  The latter approach
does sound better as a longer term solution.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.