Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: greater protection for release mode #72

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

rjzak
Copy link
Member

@rjzak rjzak commented Oct 10, 2022

  • Self-signed certificate not permitted in release mode
  • Generating a certificate is not permitted in release mode

References #49

Signed-off-by: Richard Zak [email protected]

@rjzak rjzak requested review from a team and bstrie as code owners October 10, 2022 19:47
@rjzak rjzak requested a review from rvolosatovs October 10, 2022 19:48
Copy link
Member

@rvolosatovs rvolosatovs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that solution to "having too much code" can be adding more code.

Why don't we just remove the testing code from our critical production service instead?

If we need this functionality for unit tests, then let's define clear boundaries in our internal API such that testing would be possible without modifying the implementation and be fully self-contained within the test module?

In any case, tests utilizing testing code don't test anything, those paths will never be taken in production setting, since those pieces of code will never be compiled in release mode. Note, that a mistake here could be very costly, while also being pretty easy to make. Tests must rely on "real" implementations we run in production as much as possible.

src/ext/mod.rs Outdated
@@ -28,5 +28,5 @@ pub trait ExtVerifier {
/// certificate. Returning `Ok(false)` will allow the certification request
/// to continue, but this particular extension will not be included
/// in the resulting certificate.
fn verify(&self, cri: &CertReqInfo<'_>, ext: &Extension<'_>, dbg: bool) -> Result<bool>;
fn verify(&self, cri: &CertReqInfo<'_>, ext: &Extension<'_>, dbg: &bool) -> Result<bool>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bool is Copy and small enough that & does not bring any benefits

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did that to address complaints about use of a moved value.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

strange, it just compiles fine without it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think my IDE was having problems. I reverted back to bool and it's fine.

src/main.rs Outdated
@@ -80,6 +85,7 @@ struct Args {
#[clap(short, long, env = "ROCKET_ADDRESS", default_value = "::")]
addr: IpAddr,

#[cfg(debug_assertions)]
#[clap(short, long, env = "RENDER_EXTERNAL_HOSTNAME")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Especially looking at the env var name, this parameter does not seem relevant to the Steward at it's present form

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's used to generate keys, which we wouldn't do in a production environment.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additionally, some tests were disabled for release mode (since Nix seems to test in release mode) due to this discovered bug #73

@rjzak rjzak force-pushed the debug_vs_release_checks branch from 7778951 to 2be891a Compare October 10, 2022 22:29
@rjzak rjzak requested a review from haraldh as a code owner October 10, 2022 22:29
@rjzak
Copy link
Member Author

rjzak commented Oct 10, 2022

I don't think that solution to "having too much code" can be adding more code.

I don't think I added that much code. I disabled code when compiling for release.

Why don't we just remove the testing code from our critical production service instead?

We need to have some testing (debug mode) to ensure things work in the future, since not everyone has SGX or SNP machines. The very reason for the nil and kvm backends in Enarx.

If we need this functionality for unit tests, then let's define clear boundaries in our internal API such that testing would be possible without modifying the implementation and be fully self-contained within the test module?

Sure, I can move the logic for generate() to the test side. But I still think having some debug functionally as a stand-alone executable beyond unit tests is helpful. The only part would be to ensure not using self-signed certs when compiled for release.

In any case, tests utilizing testing code don't test anything, those paths will never be taken in production setting, since those pieces of code will never be compiled in release mode. Note, that a mistake here could be very costly, while also being pretty easy to make. Tests must rely on "real" implementations we run in production as much as possible.

Again, the tests ensure the debug parts work, when utilized for actual testing. Better attestation reports and public keys can be serialized to ensure better testing #73 to fully exercise the release code.

@rjzak rjzak force-pushed the debug_vs_release_checks branch 3 times, most recently from cc1a40b to 64d7434 Compare October 11, 2022 16:45
Copy link
Member

@rvolosatovs rvolosatovs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed a few times already, deferring review to @npmccallum
I personally think that we should just remove KVM attestation and use real, captured SGX and SEV reports in tests.
If we really want to have KVM attestation available, then that should be guarded by insecure feature (as is already done) and --insecure runtime flag. Still, I am not happy by how much the implementation is changed to account for this. I find that the prevalent cfg attributes make the code harder to reason about and maintain. What's worse, it introduces plethora of new code paths, that actual, real, production service will never take and results in "real" code that should be tested to not get tested.

If we really want to have KVM attestation available, then I think we need to restructure the code in such a way that this feature would not be as intrusive and such that the unit tests would still test "real" code paths and not code paths, which would never be taken in production.

src/ext/kvm.rs Outdated
return Err(anyhow!("steward not in debug mode"));
}
#[cfg(not(feature = "insecure"))]
return Err(anyhow!("steward not in debug mode"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return Err(anyhow!("steward not in debug mode"));
bail!("steward not in insecure mode")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Captured SEV & SGX reports added yesterday.

@rjzak rjzak force-pushed the debug_vs_release_checks branch from ea1ce69 to 33c9a9e Compare October 26, 2022 15:40
@rjzak rjzak force-pushed the debug_vs_release_checks branch 2 times, most recently from c4a191a to 1954681 Compare November 7, 2022 20:56
@rjzak rjzak mentioned this pull request Dec 4, 2022
@rjzak rjzak force-pushed the debug_vs_release_checks branch from 1954681 to 0a3cb7d Compare December 7, 2022 23:11
@rjzak rjzak force-pushed the debug_vs_release_checks branch from 0a3cb7d to ab44039 Compare December 7, 2022 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants