Is Terminal app able to read chrome://policy values

[Yiyue Wang]

If I set a value for the Secure Shell extension under policy, is this value able to be read by the Terminal app?

If not, if I want to make use of the `chrome.storage.managed`, what do I do with Terminal app?

Thanks!

Yiyue

[Mike Frysinger]

this is an excellent question.  hopefully Joel knows more off the top of his head.

-mike

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/e9417b35-855e-44f1-96b1-3334eaba3e76n%40chromium.org.

[Joel Hockey]

Sorry, I'm not familiar with using policy to make data available to apps or extensions, I assume this must be a thing where you specify data for a specific extension ID?  I suspect that it wont work for Terminal since terminal is not an extensions with a normal extension id.

[Yiyue Wang]

In this case, do you have other suggestions on what might be the best if I want to have a value shared between the Secure Shell extension and the Terminal app? 

On a different note, I'm assuming Terminal app could at least receive values from `chrome.runtime.sendMessage` right? https://chromium.googlesource.com/apps/libapps/+/master/nassh/js/nassh.js?autodive=0%2F#513

[Mike Frysinger]

policy wise, I think you need to duplicate.

Terminal can send messages using that API to other extensions and receive their response. I don't think you really meant that Terminal would receive messages sent by something else.

Terminal could communicate with Secure Shell, but it's not something we generally want. Terminal is expected to work by itself without needing to install Secure Shell.

so to one of your ideas, if settings were baked into a different extension (e.g. SKE), both Terminal & Secure Shell can easily talk to it. they already do to get keys stored on the skey.

-mike 

[Yiyue Wang]

Sorry Mike for the late response. What do you think of the idea of modifying the Terminal app to be able to read from chrome managed storage?

[Joel Hockey]

I don't think it will ever be possible for terminal to use the chrome.storage.managed API since that API is heavily tied to extensions.

I think it is possible to add an extra function to chrome.terminalPrivate API that could provide data.  Maybe it could read the data associated with secure-shell extension.

The approach that I think could be good is to have SKE read from managed storage, and then let secure-shell and terminal get that data from SKE.

[Mike Frysinger]

if Terminal can't access managed storage, then it could have a unique policy defined for it, and then it'd expand the terminal private API to pass it back to the js world.

having SKE host the data is under consideration.

-mike 

[Joel Hockey]

The reason I suggested that Terminal could read the policy for secure-shell-ext is that I'm not sure how exactly policy is defined.  It is quite possible that it has to be associated with a valid extension ID.  If it is possible to use an identifier for terminal such as 'chrome-untrusted://terminal' rather than an extension ID, then yes it could have its own unique policy.

But I couldn't see how to define policy when I log into admin.google.com for my managedchrome account.  I suspect that you first select a valid extension and then associate some json object with it.  Google corp may be able to get around this since they set the policy using raw values rather than using the admin screens.

 

[Jason Lin]

The reason I suggested that Terminal could read the policy for secure-shell-ext is that I'm not sure how exactly policy is defined.  It is quite possible that it has to be associated with a valid extension ID. 

Yeah, I think for extension policy, it is defined as a json object associated with a single extension ID.

I think what Mike suggested is a good idea. We can define a new policy just for the Terminal app, and use terminal private API to read it.

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CAJJNyZbH8xqz8j9zcNYWcS0nJSvOTRDG0Ex%3D4OoeE5wrdX-Qew%40mail.gmail.com.

--

Best,

Jason Lin

[Yiyue Wang]

HI Mike,

Sorry to clarify a little bit 

> a unique policy defined for Terminal

Do you mean an extension policy defined under chrome://policy, or something else?

Regards,

Yiyue

[Joel Hockey]

It is quite a bit more code and review effort to define new policies.  It is definitely easier to get terminal to read the policy of secure-shell-ext.

To put it another way, I would be happy to help make any code updates for terminalPrivate for it to read an existing policy.  But if we need to create any new policies then I don't have the time for that

[Mike Frysinger]

i think we want to avoid Secure Shell being a hard dependency for ssh usage in Terminal.  SKE, or perhaps a new dedicated extension, would be a better option imo.

i'm getting broccoli man vibes from this whole discussion.

-mike

[Yiyue Wang]

What's broccoli man?

[Mike Frysinger]

https://youtu.be/3t6L-FlfeaI

-mike

[Yiyue Wang]

Would you prefer the option of letting the Secure shell extension read from SKE, and SKE read from its own extension policy?

Is there any concern of making the Secure Shell extension a dependency of Terminal app?

[Naqeeb Hossain]

Here is the answer,

Yes, allowing the Secure Shell extension to read from SKE (Secure Kernel Extension) and SKE to read from its own extension policy is generally preferred, and making the Secure Shell extension a dependency of the Terminal app is not a concern. This approach promotes modularity and security.

Here's a more detailed explanation:

Modularity and Security:

Separating the Secure Shell extension's configuration from the Terminal app itself allows for more flexible management and updates of the Secure Shell functionality without affecting the core Terminal application.

By allowing SKE to manage its own extension policy, you create a more secure environment, as the SKE can enforce specific security rules and access controls for the Secure Shell extension.

Dependency Concerns:

Making the Secure Shell extension a dependency of the Terminal app can create a tight coupling between the two, potentially leading to issues if one component's update or removal affects the other.

This approach also makes it harder to manage the Secure Shell extension independently, as it would be tightly bound to the Terminal app's lifecycle.

Instead, a more modular approach allows for the Secure Shell extension to be managed and updated independently, which is generally preferred for flexibility and security.

Benefits of the Preferred Approach:

Independent Updates: The Secure Shell extension can be updated and managed independently of the Terminal app, allowing for faster deployment of security patches and new features.

Enhanced Security:

By using SKE to manage the Secure Shell extension's policy, you can enforce stricter security controls, reducing the risk of vulnerabilities and attacks.

Flexibility:

The modular approach allows for greater flexibility in how the Secure Shell extension is used and configured, allowing for customization based on specific needs.

Summary:

In summary, the preferred approach is to allow the Secure Shell extension to read from SKE and SKE to read from its own extension policy, and making the Secure Shell extension a dependency of the Terminal app should be avoided due to the potential for tight coupling, reduced flexibility, and security implications.

Best Regards,

Naqeeb Hossain

[Mike Frysinger]

i have no opinion on how SKE manages the data.

-mike

[Mike Frysinger]

is this just AI generated nonsense ?

-mike

[Yiyue Wang]

Thanks Mike! Do you have any advice / feedback regarding go/ssh-host-cert-chrome? 

You received this message because you are subscribed to a topic in the Google Groups "chromium-hterm" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-hterm/RpBKdN3Z5FY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-hter...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/874c6624-5e04-44a3-b9f4-b799da6c235cn%40chromium.org.