Comment 8 for bug 1549436
Revision history for this message
| Simon Déziel (sdeziel) wrote Re: [Bug 1549436] Re: AppArmor kills StronSwan daemon 'charon' | #8 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
On 2016-02-26 01:11 PM, ruslan_ka wrote:
>> I have no idea what can cause this access to /dev/tty. I never ran into
>> this problem on my own server which is similar minus the EAP/RADIUS
>> part, I use xauth-generic only.
> xauth-eap works in a different way. It takes clear text password from client and makes EAP request to a radius server (in my case EAP-MSCHAPv2). It allows to store user passwords encrypted.
>
> Quick look through the code gives many uses for stdout (as example), but
> I'm not an expert to analyze them
> (https:/
Maybe you have some log output configured to go to stdout/stderr?
>> Again, not related but aren't the 2 rightsourceip= overlapping?
> it is a StrongSwan feature. It manages ip pool as shared in such case. You can either use
> rightsourceip=
> or just use identical definition in rightsourceip and StrongSwan will share the same pool implicitly.
It's what I assumed you were doing but your 2 CIDRs are not identical:
ikev1-psk-xauth uses a /9 and ikev2-with-eap a /16.
>> I honestly don't know why charon tries to access /dev/tty. Are you able
>> to see that message on the console or the upstart log when the Apparmor
>> profile is disabled?
> With disabled Apparmor profile everything work pretty good.
When doing the load testing, do you get something logged or displayed on
the console with the Apparmor profile disabled?
> I can provide any additional information about this system or can do
> some tests.
Well, at this point you demonstrated that you can have charon access
/dev/tty when you fully control the 2 sides of the connections (with
your load tester setup).
This means that those access to /dev/tty are quite probably not the
result of an attack of some kind. They are more likely the result of
normal operations carried by charon. As such, I feel the proper fix
would be to update the Apparmor profile to grant access to /dev/tty and
avoid causing a crash.
Regards,
Simon